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

> 1. The proposal supports %-escaping of the MIME type, as far as I can tell.

The main reason was because otherwise you could not have a MIME type with a comma in it. I don't think Chrome and Safari have proper support for it. They don't normalize `text/pl%61in` to `text/plain`. And they render `data:text/htm%6C,<b>test` as text (`<b>test`). I guess I'll remove that since you're the second one to complain about it.

> 2. `data:text/plain;foo=';base64;',stuf` [I removed the final f  to make it forgiving-base64-compatible]

This does not work in Safari, but does work in Chrome. I would prefer it not working.

> 5. This spec allows `;charset=stuff` to come after `;base64`.

Something like `data:text/plain;base64;charset=utf-16,stufstuf` gives three results. Firefox treats it as base64, but not UTF-16. Chrome treats it as base64 and UTF-16. Safari applies neither and renders "stufstuf".

I think we should either require `;base64` to be the actual last thing as per the RFC or allow it to occur anywhere. Some kind of mix seems rather confusing.

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

Safari never expands (just uses the given value as MIME type) and Chrome and Firefox prepend `text/plain` even if it doesn't start with `;charset`. @TimothyGu pointed this out first and I guess I was wrong to dismiss it.

> 7. At least Gecko canonicalizes the actual MIME type to lowercase for data:, just like it does for HTTP and every other network protocol.

Safari does not, Chrome does.


I'll go ahead and update the proposed standard and tests per the above.

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