| Summary: | Parse content after # in data URLs with HLS mime types | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alex Christensen <achristensen> | ||||||||||
| Component: | New Bugs | Assignee: | Alex Christensen <achristensen> | ||||||||||
| Status: | RESOLVED FIXED | ||||||||||||
| Severity: | Normal | CC: | cdumez, darin, eric.carlson, ews-watchlist, glenn, japhet, jer.noble, philipj, sergio, webkit-bug-importer | ||||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||||
| Version: | WebKit Nightly Build | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Alex Christensen
2020-12-07 13:27:36 PST
Created attachment 415576 [details]
Patch
Comment on attachment 415576 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=415576&action=review > Source/WebCore/platform/network/DataURLDecoder.cpp:48 > +static bool shouldRemoveFragmentIdentifier(const String& mediaType) I’d like to see a "why" comment mentioning the reason for the MIME type special cases here. Also wondering if we will keep this forever. > Source/WebCore/platform/network/DataURLDecoder.cpp:55 > + return !equalIgnoringASCIICase(mediaType, "video/mpegURL") > + && !equalIgnoringASCIICase(mediaType, "audio/mpegURL"); This could instead be written in this slightly more efficient way: return !equalLettersIgnoringASCIICase(mediaType, "video/mpegurl") && !equalLettersIgnoringASCIICase(mediaType, "audio/mpegurl"); > Source/WebCore/platform/network/DataURLDecoder.cpp:127 > - const String urlString; > + URL url; This is a much bigger object. Is that OK? Comment on attachment 415576 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=415576&action=review > Source/WebCore/platform/network/DataURLDecoder.cpp:54 > + return !equalIgnoringASCIICase(mediaType, "video/mpegURL") Would be nice if this was turned off if "Disable Site-specific Hacks" was set. While we are not limiting this to a particular website, turning this off to test if the website works without the quirk is something that fits the mission of that menu item and switch. Comment on attachment 415576 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=415576&action=review >> Source/WebCore/platform/network/DataURLDecoder.cpp:54 >> + return !equalIgnoringASCIICase(mediaType, "video/mpegURL") > > Would be nice if this was turned off if "Disable Site-specific Hacks" was set. While we are not limiting this to a particular website, turning this off to test if the website works without the quirk is something that fits the mission of that menu item and switch. Do non-Apple WebKit ports want this quirk? I’m guessing no, since they don’t have HTTP Live Streaming. From what I understand, this is not site-specific or likely to go away because HLS manifests use # in the middle and aren't about to stop. I will restrict it to cocoa platforms, though. A URL is 32 bytes bigger than a String, but that's not significant compared to sizeof(DecodeTask) plus typical data URL sizes, and it's a very short-lived object. We need the URL to know where to start removing the fragment that we've already found when parsing the URL. Created attachment 415581 [details]
Patch
Created attachment 415588 [details]
Patch
Comment on attachment 415588 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=415588&action=review > Source/WebCore/platform/network/DataURLDecoder.cpp:58 > + return !equalIgnoringASCIICase(mediaType, "video/mpegurl") > + && !equalIgnoringASCIICase(mediaType, "audio/mpegurl") > + && !equalIgnoringASCIICase(mediaType, "application/x-mpegurl") > + && !equalIgnoringASCIICase(mediaType, "vnd.apple.mpegurl"); This lowercases things as required by equalLettersIgnoringASCIICase, but didn’t add the word "Letters" to the function name. Created attachment 415591 [details]
Patch
Committed r270526: <https://trac.webkit.org/changeset/270526> All reviewed patches have been landed. Closing bug and clearing flags on attachment 415591 [details]. |