Re: [whatwg/fetch] Define opaque-response blocking (updated) (PR #1755)

zcorpan left a comment (whatwg/fetch#1755)

Media findings:

Unlabeled responses to media requests are blocked unless they sniff as audio or video (step 8). Gecko does this; Chromium allows them. Unlabeled responses to non-media requests are allowed in the spec, Gecko, and Chromium, so the bigger gap is annevk/orb#28. Step 8 doesn't cost compat for media, though, so it fits ORB's objective.

Our proposal is to keep step 8 and align with Gecko otherwise:

- Allow `application/vnd.apple.mpegurl`, `audio/mpegurl`, `application/dash+xml`, and `text/vtt` without sniffing, and remove the first and third from the never-sniffed list. Gecko does this (bug 1698040) and Chromium safelists them.
- Allow `audio/mpeg`, `audio/aac`, `audio/aacp`, and `multipart/x-mixed-replace` without sniffing. Some MP3 servers aren't sniffable mid-stream. That's what Gecko does; Chromium safelists all `audio/*` and `video/*`.
- Add Gecko's media signatures to mimesniff's audio or video pattern matching: MPEG-TS, ADTS (whatwg/mimesniff#114), more MP4 brands (whatwg/mimesniff#149), FLAC, Matroska, and `#EXTM3U`.
- Sniff playlists at each step, since entries can point to arbitrary cross-origin URLs, including nested playlists.
- Block `text/plain` with nosniff, as Chromium does and the spec does since 173b75d. Gecko will drop its exception ([bug 2089487](https://bugzilla.mozilla.org/show_bug.cgi?id=2089487)). Tested in web-platform-tests/wpt#64714.
- Chromium would need to add step 8, after the new mimesniff signatures land so unlabeled HLS segments and MP3 streams don't break.

Does this work for Chromium and WebKit?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1755#issuecomment-6655450816
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1755/c6655450816@github.com>