Re: [whatwg/fetch] Define data: URLs (#579)

@achristensen07 

> Making Safari support ";base64," and ";base64;" would probably be no big deal, especially if 3 other engines support it.

The detail which appears to be unique to WebKit/Safari, and which this PR matches, is to only look for a ASCII case-insensitive match for ";base64" at the end of the MIME type, although because of how the input is split and stripped of whitespace, "data:text/plain;base64 ,WA" also works.

> I'd prefer not to allow whitespace in a data URL

Do you mean whitespace anywhere, or in some specific part of the syntax? To minimize the cases where whitespace is skipped is to maximize the compat risk of this change, so I've been arguing above for allowing it in every context where any engine current does.

> I'd really like to be able to parse a data URL without looking through the base64 encoded bytes twice. It could get really slow if you have a data URL of many megabytes of base64 data and we must look through it twice to see if it's a base64-encoded data URL.

As now written, one needs to parse only the substring before the first comma in order to determine whether the part after the comma is base64 encoded or not. This would be true regardless of how whitespace is handled within that substring.

Out of these concrete options, do any seem particularly good or bad?
* The PR exactly as it currently is (matches Safari rather than Chrome/Edge/Firefox on most ";base64" tests, but still differing from Safari on plenty of other tests)
* Making https://mimesniff.spec.whatwg.org/#parse-a-mime-type find the "base64" token (@annevk says [rather ugly](https://github.com/whatwg/fetch/pull/579#issuecomment-355314691) and I don't disagree)
* Making the pre-processing exactly *as if* we'd done the above step
* Only looking for the "base64" token at the end of the input, but skipping more whitespace

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