The IE10 nosniff issue in SharePoint 2013
Last week was fun (and no this isn’t a post about not sneezing when using IE10)! We had two major issues still to overcome in DocRead for SharePoint 2013 before we could release it. So I decided to help out and take a look. BTW, if you are using JSON in SharePoint 2013 you may just get caught by this, so it’s worth 5 minutes.
What were the issues ?
- Telerik ReportViewer doesn’t work in SharePoint 2013.
- One of our JSON calls (to confirm a document), was also failing badly.
What were the symptoms ?
- For Telerik, the reports just didn’t show – no error information, nothing. (Only in IE10)
- For our JSON call, IE10 made the call, but wouldn’t load our object after it – again very little error information apart from our local variable was always null (undefined).
What we originally thought were two separate issues – were in both in fact caused by the same thing. The “nosniff” header. You may not know, but SharePoint 2013 web applications are automatically configured to send down a “HTTP Response Header” called “X-Content-Type-Options” with a value of “nosniff”. See below :
If I removed this header, then both problems disappeared. Not something I can ask customers to do though is it ?!?
So what on earth is the “nosniff” header ?
There’s a good article on the reason for the nosniff header here :http://htaccess.wordpress.com/2009/09/22/x-content-type-options-nosniff-header but in short it’s a directive from IIS that tells the browser to not sniff the MIME type. I am no browser security nerd, so I don’t claim to fully understand this. I think “in simple terms”, when this is disabled IE won’t try to automatically determine what your content is. E.g. HTML, PNG, CSS, script, etc…
This means that it’s up to you (the developer) to tell the browser what your content is. And, if what you are sending down isn’t in IE’s allowable list, it’s going to kick and scream, or more realistically refuse to execute your content, hence the blank areas of the screen.
To quote the page list above “if the “nosniff” directive is received on a response retrieved by a script reference, Internet Explorer will not load the “script” file unless the MIME type matches one of the following values…”.
This is what has happened in both of our cases. My prediction is there’s going to be absolutely loads of issues with people converting 2007 and 2010 apps to 2013!
In the first case, Telerik were declaring some of their Javascript with a MIME type of “text/blank” when it should have been “application/javascript” and in our case, we were sending our JSON down as “application/json” when it should have been ‘probably’ “application/javascript” to pass through that list.
How did we fix it ?
In Telerik’s case – they know about it and will fix it themselves eventually. However, as we can’t wait, we have implemented a fix for both in an HttpModule which is described next.
In your HttpModule you want to wire up the ReleaseRequestState handler, as follows :
Your ReleaseRequestState, should look something like this. In effect this is changing the Content Type of the content to something will play ball with IE10 just before it goes to the browser.
Obviously, if you change the content type at the source this is much better, but in both our cases we were unable to. One other thing to note, we use conditional compilation to support 3 versions of SharePoint so where you see “#if SP2013” that’s because we only want the code to be compiled in for 2013 as that’s where the problem lies. To learn more about upgrading an custom application to 2013 please look at ‘Upgrading a custom application to SharePoint 2013‘