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

So observably, the MIME type bit just affects what getResponseHeader("Content-Type") returns for data: URIs with parameters in the MIME type, right?

In practice, I expect that including parameters (but not the ;base64 parameter) in there is fairly compatible, in the sense that no one uses those to a first approximation.

Looking at the actual spec proposal, I have the following questions:

1. The proposal supports %-escaping of the MIME type, as far as I can tell.  So it would support `data:text/pl%61in,some text` or so.  I guess WebKit and Blink support that, but Gecko does not.  Does Edge?  Is there a reason we'd actually want to support it?  It seems like an avenue for filter bypasses...
2. This spec will, I think, treat `data:text/plain;foo=';base64;',stuff` as a base64-encoded URI.  I think that matches Gecko; dunno about other browsers, and not sure what behavior we actually want here.
3. "forgiving-base64 decode" is not linkified.  It should be.  Presumably it's https://infra.spec.whatwg.org/#forgiving-base64-decode
4. The definition of "valid MIME type" is not linkified...  I have no idea what browsers do here in practice.
5. This spec allows `;charset=stuff` to come after `;base64`.  Is that needed for compat.  The data: RFC requires that `;base64` come last, and at least Gecko semi-enforces that by ensuring that charset is not looked for after `;base64`.
6. For something like `data:;foo=bar;charset=UTF-8` it looks like the proposed algorithm will treat it as `text/plain;charset=US-ASCII`, right?  What do UAs do here?
7. At least Gecko canonicalizes the actual MIME type to lowercase for data:, just like it does for HTTP and every other network protocol.  This spec doesn't do that at this level, but maybe higher levels end up doing it?  What do other UAs do?

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