Page MenuHomePhabricator

no content sniffing headers break js for ie9
Closed, ResolvedPublic


Since the fix for Bug #15461, we are telling browsers not to sniff content when we serve js with action=raw. At least IE9 and probably IE8 have problems. Probably the JS needs to be fixed to do ctype=text/javascript, but I'm filing this in case there are other possible solutions.

Version: 1.18.x
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:48 PM
bzimport set Reference to bz31400.
bzimport added a subscriber: Unknown Object (MLST).

IE8 seems to take it even though it shouldn't. ;)

IE9 does reject the text/x-wiki script when we send X-Content-Options: nosniff -- this is probably correct behavior for it to do, and should be expected from at least some other browsers.

Anything that's loading up JS via action=raw needs to use &ctype=text/javascript -- stuff using importScript should already be using this and should be fine.

"SCRIPT and STYLESHEET elements will reject responses with incorrect MIME types if the server sends the response header X-Content-Type-Options: nosniff. This is a security feature that helps prevent attacks based on MIME-type confusion."

Actually I think I see where this is happening!

The problem is the 'action=raw' without the ctype parameter... we guessed people were doing these manually, but I don't think they are.

importScript correctly adds the &ctype=text/javascript .... but it can get stripped in a redirect case.

The affected user's vector.js page loads up what's meant to be the same user's monobook.js by doing an importScript on a Special:MyPage subpage:


This goes off to load the very sensible:


That then redirects us to the actual user page.... and drops the ctype parameter:

So the actual bug looks like Special:MyPage not forwarding other query string parameters.

Fixed on trunk in r99067 and REL1_18 in r99068.

Not merging to 1.18wmf1 to make sure we don't accidentally think it's already merged.