-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MIME type parsing, stricter rules #44
Comments
I think that parser is just used in tests to judge pass/fail, not for deployment in Chrome. |
How would you pass those tests then though? |
The tests are actually loosening the requirements by testing that the browser's output parses into the right value, instead of just testing the browser's output for an exact string match. In other words, they don't really test parsing, just serialization. |
I see; I'd like us not to go in that direction. Maybe I should put up my own proposed modifications for that test for comparison. |
Created web-platform-tests/wpt#8422. |
Closing this as a duplicate of #39 as that one is also focused on the XMLHttpRequest angle and there's not really anything new here apparently. |
In https://chromium-review.googlesource.com/c/chromium/src/+/773321 @yutakahirano and @tyoshino work on a MIME type parser for XMLHttpRequest that is quite a bit stricter than the proposal in #36 (though not as strict as the RFC as far as I can tell; failing on
text/html;
would also undoubtedly break sites). If we can actually use that all over the web platform that is arguably somewhat better.This is to track its success. I'd rather not block #36 on the outcome, but use the outcome to further refine the tests already written and the standard itself.
The text was updated successfully, but these errors were encountered: