Traditionally as a SharePoint developer or designer your skills and toolkit were quite different from those of a standard web developer. While that used to be essential to your success, in today’s web-centric world as you transition your skills it might mean you overlook the obvious when troubleshooting. Recently I was helping a developer colleague resolve one of those eponymous “Sorry, something went wrong” messages that SharePoint 2013/2016 is so famous for, when it drove home this point: Always start with the web-dev basics!

In the old school approach as a SharePoint dev whenever there is an error in my solution I almost always start with the ULS logs. But in this case SharePoint isn’t giving anything away for free, no correlation id is offered for us to look up.

My colleague and I are about to launch into SharePoint server-side ninja debugging but something makes us stop and we take a step back to re-consider our approach.

Don’t be hasty, perhaps there is a client-side issue, we say to ourselves. Ah yes, time for every web developer’s true friend, the F12 developer tools! Duh-da-da-dah!

If our issue is client-side then one of the first places to check is JavaScript code: In the F12 developer tools on the Debugger tab we turn on Break on all exceptions:

Then we re-load the page, but no love, still the same “Sorry, something went wrong” and no JavaScript exception.

Ok so it probably isn’t a JavaScript issue. What next? Oh yeah, we skipped a step, should have started with the Console tab:

Now we are getting somewhere: The browser threw a couple of SEC7112 warning on ~/layouts/15/AccessDenied.aspx:

HTML1300: Navigation occurred.
File: results.aspx
SEC7112: Script from http%3A%2F%2FXXXXX/sites/Picasso/_layouts/15/AccessDenied.aspx?Source=http%3A%2F%2FXXXXX%3A81%2Fsites%2FPicasso%2F%5Fcatalogs%2Fmasterpage%2Fdisplay%20templates%2Ffilters%2FXXXXX%5Ffilter%5Fmultivalue%5Fmultilang%2Ejs%3Fctag%3D444%24%2415%2E0%2E4753%2E1000&Type=item&name=7682e984%2D9fa9%2D4945%2Db6e4%2D1e5152a1ce1d&listItemId=360 was blocked due to mime type mismatch
File: results.aspx

Yeah, but what is a “SEC7112: Script from … was blocked due to MIME type mismatch” error, you might ask? MSDN Library provides a succinct answer in its Web Development series under Internet Explorer, HTML and DOM compatibility changes: Reducing MIME type security risks:

The 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.

In layperson terms, Internet Explorer requested a script or stylesheet resource from SharePoint as part of fulfilling the results.aspx page, but the response from SharePoint did not have a corresponding acceptable MIME type, and SharePoint sent the response header X-Content-Type-Options: nosniff, so the browser blocked the response. The MSDN article lists the acceptable MIME types for each of a script of stylesheet resource, for example:

• txt/css for a stylesheet resource
• txt/javascript
• etc (several other MIME types) for a script resource

Hmmm, yeah right, so what does that have to do with loading ~/layouts/15/AccessDenied.aspx? And why was the browser requesting, or more likely receiving, an AccessDenied.aspx response from SharePoint when it was supposed to be loading results.aspx?

We haven’t gotten to the bottom of this story yet!

Looking in more detail at the AccessDenied.aspx page URL we see that it provides an encoded URL query string parameter, the URI that causes the denied access:

~/catalogs/masterpage/display%20templates/XXXX_filter_multivalue_multilang.js

Time to call on another of the F12 dev tools, the Network tab, which shows every single page and resource request and response between the browser and the server to fulfill the original page navigation:

There we see the same JavaScript resource file:

~/catalogs/masterpage/display%20templates/XXXXX_filter_multivalue_multilang.js

But this time with an HTTP 302 Found response code. Now that seems puzzling, why does a JavaScript resource request cause SharePoint to respond with an HTTP 302 response code and the AccessDenied.aspx response page? Time for a quick refresher on HTTP 302:

HTTP 302 Found means that a page or resource is temporarily not at the URL in the original request but will be found at another URL indicated in the response headers.

Let’s dig a bit deeper and look at the Request Headers:

Text version of those headers:

Key	Value
Request	GET /sites/Picasso/_catalogs/masterpage/display%20templates/filters/XXXX_filter_multivalue_multilang.js?ctag=444$$15.0.4753.1000 HTTP/1.1
Accept	application/javascript, */*;q=0.8
Referer	http%3A//XXXX/sites/Picasso/en‑ca/Pages/results.aspx?k=*
Accept-Language	en-CA
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding	gzip, deflate
Host	XXXX
DNT	1
Connection	Keep-Alive
Cookie	0c37852b34d0418e91c62ac25af4be5bb9842ff7410b4a84a5af7cc5b6cf4542XXXX=0; WSS_FullScreenMode=false

Note the request header Accept shows that MIME type application/javascript is preferred.

And looking at the Response Headers:

Text version of those headers:

Key	Value
Response	HTTP/1.1 302 Found
Location	http%3A//XXXXX/sites/Picasso/_layouts/15/AccessDenied.aspx?Source=http%3A%2F%2FXXXXX%2Fsites%2FPicasso%2F%5Fcatalogs%2Fmasterpage%2Fdisplay%20templates%2Ffilters%2FXXXXX%5Ffilter%5Fmultivalue%5Fmultilang%2Ejs%3Fctag%3D444%24%2415%2E0%2E4753%2E1000&Type=item&name=7682e984%2D9fa9%2D4945%2Db6e4%2D1e5152a1ce1d&listItemId=360
Server	Microsoft-IIS/8.5
X-SharePointHealthScore	0
X-Powered-By	ASP.NET
MicrosoftSharePointTeamServices	15.0.0.4753
X-Content-Type-Options	nosniff
X-MS-InvokeApp	1; RequireReadOnly
Date	Tue, 18 Oct 2016 20:42:01 GMT
Content-Length	479

Note the response header X-Content-Type-Options with the value nosniff as expected given the SEC7112 warning. But why the HTTP 302 Found response code and the redirect to AccessDenied.aspx? We are still puzzled by all these warnings and response codes.

The next step seems to be to directly request the script file and see if we can retrieve it.

Well we knew already that from the first console warning, sort of, but now the situation is clearer: The original Sorry, something went wrong message is because we are not permitted to retrieve one of the display templates (script resources), XXXX_filter_multivalue_multilang.js, referenced on the main page results.aspx.

Let’s have a look at this file in the SharePoint Master Page Gallery library. First we check the permissions on the file and its parent library and site. Those all check out, access is granted to Restricted Reader and our current logged-in to SharePoint account / AD user / AD group is a member of this SharePoint security group.

[Insert image: permissions]

Second we check that this display template has at least one published major version, since Restricted Readers won’t see draft versions.

Bingo! So there we have it. No published major version means our test user account which is only in Restricted Readers can’t access the file, hence AccessDenied.aspx was returned by SharePoint.

Here in summary is the chain of events when we browser to results.aspx:

1. Browser requests results.aspx page with various css and script elements
2. Browser requests each of the css and script resources, including XXXX_filter_multivalue_multilang.js
3. SharePoint receives the script resource request and applies security trimming
4. There are no published major versions of the script resource
5. Current user as a member of Restricted Readers does not have permission to access a file with no published major version
6. SharePoint responds with the AccessDenied.aspx page and an HTTP 302 Found status code to indicate that it is a temporary redirect, and MIME type text/html
7. Browser receives SharePoint’s response but was expecting a script resource MIME type, eg txt/javascript
8. Browser throws a SEC 7112 warning because the MIME type is not correct
9. In lieu of the missing display template results.aspx page displays the eponymous message Sorry, something went wrong

Thankfully it is a simple fix, we publish a major version of the script file:

And now the search results page loads correctly, including the missing search refiners:

And the F12 Developer Tools tabs are clean, in the Console tab there are no more SEC7112 errors, and in the Network tab there are no more HTTP 302 response codes.

In summary, in today’s day and age as a SharePoint developer when you are troubleshooting web page issues it is essential to know how to effectively use the browser F12 developer tools as your first point of discovery and investigation.

Happy developer happy business client!