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

> It sounds like Chrome is not willing to change to more closely follow RFC 2397 and Firefox has already followed them because of existing content. It sounds like I'm probably going to be unable to change the outcome of this discussion.

I defer to @mikewest to say what Chrome is willing to try or not, but all implementations will need to change in some way. In cases where taking some moderate compat risk seems like the only way to reach interop ([example](https://groups.google.com/a/chromium.org/d/msg/blink-dev/tWzutytXsqc/lGaWCFdHAgAJ)) then I'm usually all for that, so it's not a "Chrome will never break anything" argument I'm making. (Haven't been accused, just saying.)

Since https://mimesniff.spec.whatwg.org/#parse-a-mime-type skips whitespace in all the relevant places, what remains to debate is how to deal with the "base64" token.

Given the findings in https://github.com/whatwg/fetch/pull/579#issuecomment-355277625 I really would like to make at least a trailing "; base64" work, but the out-of-order "text/html;base64;more=stuff" could be added only if get real-world regressions.

@annevk @achristensen07, how would you feel about looking for a trailing (case-insensitive) "base64" preceded by optional whitespace and then ";"? That'd make it seem like the "whitespace tolerance" is consistent, while still keeping "base64" out of the MIME type parser.

(Whether it's removed from the input doesn't really matter to me since the MIME type parser would ignore it anyway.)

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