[padenot]

This seems to be mostly mobile-only, because m3u8 are only played on mobile. Chrome, Firefox and Safari can play those files on mobile. Chrome and Safari don't require a particular Content-Type.

Firefox requires the right mime type to be sent because it didn't have a way to sniff for those files, but this is changing, and it's best to normalize how to sniff.

Safari can additionally play those files on desktop, regardless of the Content-Type sent by the server.

• At least two implementers are interested (and none opposed):
  • Firefox plays it
  • Chrome plays it
  • Safari plays it
• Tests are written and can be reviewed and commented upon at:
  • I didn't find a test infrastructure with test vectors, and I don't know of a way to check the content type sniffed by an HTMLMediaElement. I suppose we can try to load the resource with a web server that forces application/octet-stream or the like, but that requires a server-side component.
• Implementation bugs are filed:
  • Chrome: This has worked for a long time there
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1550248 (solely about sniffing, it already plays with the right Content-Type
  • Safari: This has worked for a long time there

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

---

💥 Error: 422 Unprocessable Entity 💥

PR Preview failed to build. (Last tried on Nov 4, 2026, 4:57 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build bikeshed/ReSpec specs

🔗 Related URL

Error output:

[
    {
        "lineNum": "196:44",
        "messageType": "link",
        "text": "Obsolete biblio ref: [rfc7231] is replaced by [rfc9110]. Either update the reference, or use [rfc7231 obsolete] if this is an intentionally-obsolete reference."
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]

This seems to be an issue with the Spec Generator service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can report the issue to the maintainers of Spec Generator directly. Please be courteous. Thank you!

If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can file an issue with PR Preview.

[domenic]

Awesome! Can you become a member of https://github.com/mozilla-standards/, or publicize your membership?

As for tests, historically we don't have many/any for the MIME sniffing algorithms, but I think it'd be worth adding some if it's not impossible. Web platform tests definitely supports the appropriate server infrastructure; you can set arbitrary headers.

[padenot]

Awesome! Can you become a member of https://github.com/mozilla-standards/, or publicize your membership?

Yes, thanks, Anne had invited me but my membership was private.

As for tests, historically we don't have many/any for the MIME sniffing algorithms, but I think it'd be worth adding some if it's not impossible. Web platform tests definitely supports the appropriate server infrastructure; you can set arbitrary headers.

This is tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1656495. We have tests for most of this in Gecko, I need to see if it would be possible to convert to wpt (it's using internal gecko things to hook into the sniffers themselves, but the test vectors are nice).

[GPHemsley]

@padenot Are you sure that Chromium is sniffing this? I'm not seeing it in their sniffing code:
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/net/base/mime_sniffer.cc
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/net/base/mime_sniffer_unittest.cc

Though, as you well know, Firefox is:
https://hg.mozilla.org/mozilla-central/rev/0bed87941dc5
https://hg.mozilla.org/mozilla-central/file/default/toolkit/components/mediasniffer/nsMediaSniffer.cpp

(As I mentioned in #150, support for a format does not necessarily imply that sniffing is also being done.)

[padenot]

Looks like Chrome and Safari (at least desktop) don't sniff it indeed [0], curiously. It's however mandatory to implement HTMLMediaElement (the Content-Type is to be ignored), so there should be steps to sniff here.

[0]: I tested serving a HLS playlist file with application/octet-stream and no extension as the src attribute of an HTMLMediaElement, and seeing what implementations do. Firefox plays it, Safari and Chrome don't.

[GPHemsley]

It's however mandatory to implement HTMLMediaElement (the Content-Type is to be ignored), so there should be steps to sniff here.

I'm not seeing anything in Media elements that indicates that sniffing is mandatory, though I am seeing lots of conflicting and underspecified things. I'm guessing the connections between HTML and mimesniff need to be made more robust.

In the meantime, can you point to where you're interpreting as indicating sniffing is mandatory?

[annevk]

Yeah, I think Chrome and Safari do require a MIME type for this. See whatwg/html#6468 for the corresponding HTML issue.

I guess that means we should adjust Firefox and close this PR?

[GPHemsley]

I have confirmed that Chrome identifies this as text/plain.