- 0 Comments
- November 8, 2013
- by David Lohnes
- Leave a comment
Recently we were asked to troubleshoot an issue a client was having with their production 2010 SharePoint environment. The basic error report was that very intermittently and unpredictably, users would navigate to a normally reliable SharePoint site and find it completely broken. Text might be scattered all over the page in abnormal ways, or whole sprites might be visible to the user.
One of the client’s web developers had identified the issue as related to a specific CSS file, but they didn’t know the cause, and they didn’t know how to fix it, and they asked for our help.
The problem CSS file was SharePoint’s core CSS file: corev4.css. The file would be delivered to the browser with 0k size–no data within. As a result, the pages would be almost entirely devoid of CSS when rendered by the browser.
The question was, why was corev4.css coming to the browser with zero contents?
It was not a simple investigation.For one thing, the issue was quite intermittent and difficult to replicate. For another, the customer’s SharePoint environment has many potential culprits. The farm has multiple web applications with different settings and app pools, and it is located at a central datacenter which is accessed by users on other continents. Between the farm and the users they have a network load balancer and, depending on user location, possibly a network accelerator. Each of these devices is capable of caching data to deliver to users, and each is managed by a different team.
Initial testing showed that the issue could occur in situations that did not involve the network accelerator, so that device was ruled out as the source of the problem. It seemed unlikely that SharePoint would randomly serve a critical CSS file with nothing in it, but despite repeated looks at the network load balancer, the issue could not be definitively traced to its caching. Furthermore, it seemed that one web application in particular suffered the issue more than the others. That left the possibility that the issue was a SharePoint issue.
During the course of the investigation, I found a successful workaround.
The URL of the CSS in question was: /_layouts/1033/styles/Themable/corev4.css?rev=3TRomkG1g2gMGz4rekMIQg%3D%3D
The long rev number is the MD5 hash generated by the SPUtility.MakeBrowserCacheSafeLayoutsURL method as part of CSS registration to bust the user’s browser cache when a file has been updated on the server (another good background post here). Because it’s an MD5 hash, the rev number is unique to each particular version of the file (which is how the system knows the file has really changed), and in this case simply indicated the corev4.css file for the particular version of SharePoint the customer had installed.
The key to the workaround is that only the default out-of-the-box site theme calls directly for corev4.css by its rev number. Every other theme calls instead for a ?ctag= denominated CSS file that dynamically incorporates all the style changes associated with the new theme. Once a theme was applied to a site, it invariably remained free from the issue.
Sadly, we never actually got to the bottom of the issue because the customer was satisfied with this workaround and did not wish to pursue the matter further.