Open Bug 1333995 Opened 4 years ago Updated 1 year ago
Return a network error for requests whose type is "script" with additional bad MIME types (round 2)
+++ This bug was initially created as a clone of Bug #1299267 +++ Now that improved telemetry (and some blocking) has made it to Firefox 51 it looks like we're clear to follow the "must not" in the HTML spec and block additional types: text/xml 0% application/xml 0.01% Without careful investigation it would be dangerous to block text/plain (0.71%, a billion loads). We might be able to block application/octet-stream (0.08%, 144 million loads). Telemetry (beta 51): https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-01-18&keys=__none__!__none__!__none__&max_channel_version=beta%252F51&measure=SCRIPT_BLOCK_INCORRECT_MIME&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-11-15&table=0&trim=1&use_submission_date=0  https://www.w3.org/TR/html5/scripting-1.html#scriptingLanguages
1) We should use https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages. 2) That list and the requirements around it are meanly meant for <script type>. They are not meant to apply to network fetches. I filed https://github.com/whatwg/html/issues/2301 to clarify that. 3) Nevertheless, blocking more MIME types and adding those to https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? seems reasonable.
I'm not following your comment. We cannot blindly implement the spec without knowing what we will break. We implemented telemetry to know what will break. Right now we're working on the second list at your reference "must not be interpreted as scripting languages:" and telemetry seems to say we can forbid the xml ones but probably not text/plain. Maybe later we can get to the "only allow these explict script types" state, but that's not where we are.
Priority: -- → P3
I'm saying that the HTML Standard does not say what you think it says. It does not require that the response of a <script src> fetch has a correct MIME type. The list of MIME types listed there is used for <script type> and Fetch uses it for "nosniff". (Very deliberately, we don't want to require things that can't be shipped.) The next point I made was that figuring out if we could block more MIME types and add those to Fetch (https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? in particular) as we go seems worthwhile, provided other browsers do the same (and block them in the same way, we've had some fallout because Chrome doesn't do the same kind of checks for importScripts() and such).
New data since bug 1510225 landed: https://mzl.la/2GxHc9Q. "application/json" is huge probably JSONP endpoints.
You need to log in before you can comment on or make changes to this bug.