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

@achristensen07 

> @foolip you say there are 429 data URLs with a space in them in HTTPArchive.  How many data URLs are there?  I think that is an incredibly low percentage, if Chrome and Firefox started not allowing a space they would be fixed, and that would be the right thing to do.  I do not think we should allow whitespace, and valenting's referenced comments reference a 6 year old bug that does not have a space in the data URL.

429 was with space in a specific location ("; base64") but I'm just matching regexes without trying to parse it as HTML or CSS, then looking for interesting real cases, so I don't know what proportion of data: URLs in the wild have spaces somewhere, or other errors per the RFC.

> I don't feel as strongly about allowing semicolons instead of colons or allowing base64 in different locations before the actual encoded data.  I'd like to be stricter, but it wouldn't bother me too much if we all became more permissive together in a well-defined manner.

That's not part of https://whatpr.org/fetch/579.html, or at least the colon in "data:" is just a colon. Is it something else that I've missed?

> Is there significant non-browser use of data URLs?  They would probably respect the RFC over the fetch spec.

That sounds likely, yes.

My argument is that to minimize compat risk for everyone and resolve this issue forever ASAP, we should allow spaces where any browser currently allows it, do case-insensitive matching where any browser currently does, and so on. AFAICT the spec's pretty close to that, with the exception of base64 handling.

We could take the path of maximizing alignment with the RFC if all implementers are on board with that, but it's a certainty that some content out there would break in some browsers, and to me this just seems like a pointless thing to ask web developers to deal with.

-- 
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-358353692