You all (should) know that since 1st April, SharePoint Designer is free. Since that, there also was a lot of buzz around it as well as interesting blog posts like the one from Mark Rackley SharePoint Designer – A definite Maybe, echoed by SharePoint Mogul Joel Oleson. While both were very interesting readings, one statement from Mark caught my attention: Using SharePoint Design would break IIS Compression. I don’t totally agree with this statement but the truth is (not only out there but) more complex than it seems.
Before diving directly into the bits and bytes, some background information over how HTTP compression works.
The effective HTTP compression by a web server is the combination of two thing: the client that sends a request specifying that it support compression and the server, receiving that requests, which is configured to support and therefore return as compressed response. That compressed response is conditioned by the type of compression supported by the client and the server (there are currently two: Deflate or Gzip) and the server’s configuration: compress all file extension, or only some of them. There are also, on IIS, two kind of file extensions: the static (simple files placed on the file system like a css, and image, an html page) or dynamic (dynamically generated content like ASP, ASP.Net pages, ASMX…). Additionally, IIS also includes more granular settings like the minimum file size for a file to be compressed (there is no gain in compressing very small files).
The important point here is: if the client does not explicitly says it supports compression, the server will never generated a compressed response, even if it was configured to do so!
While all modern browser do include the magic header informing the server they support compression, other client types (I mean other usual SharePoint client types), do not.
As a comparison, here is a request from a browser:
And here is one from the WebDav Mini Redirector (aka Explorer view in SharePoint aka Web Folders aka Web Client):
The conclusion is: most of time, only standard browsers do support compression. Clients like Windows WebDAV client, Office Application (using FPRPC, an MS proprietary extension of WebDAV), Colligo Reader and even the SharePoint Indexing process (aka Crawler) never include the necessary header in their requests.
The extra complexity brought by SharePoint: is the resource on the file system or in the content database?
With SharePoint, some resources requested by clients may be physically stored in two different locations: the file system (usually under the 12 Hive) and the content database(s). When they reside in the content databases, SharePoint uses its internal API to fetch them and present them to the client. In this case, the questions are 1) are those files compressible or not 2) how are they considered: as static or dynamic files (even if their extension is the one from a static file, like html for example).
Subsequently, a very good remark from MVP Eric Schupps on Mark Rackley’s blog was: when you customize a page using SharePoint Designer, it is no longer stored store in the file system but in the CDB instead and this makes it impossible to compress.
I am a bit surprised by this statement because for me, compression is an IIS function, not a SharePoint function. Therefore, as long as IIS received something to compress, it does not care and does the job. The truth (which is still out there) is different: none of use was right, the reality is more complex than that!
Getting the resources stored in content database compressed
For extensions considered as “dynamic”, it is pretty simple: configure them as usual in IIS and it will work
For extension considered as “static”, there is more fun. Let take the example of a pdf file stored in a CDB.
Out of the box, it will not get compressed. If you configure it as a “static” file, it won’t compress either.
How to get it compressed then? First you need to configure it as a “dynamic” extension (yeah, sound strange I know), in both compression providers (Deflate and GZip).
Then,you need to enabled Blob Caching for you web application where the content is stored. To do this, edit the matching Web.config as it is below
Finally, perform an IISRESET and attempt to doanload the PDF file. The PDF will get blob-cached then compressed
Configuration Summary Table for IIS Compression to Function
|Content Type||Content Location||Configure IIS to Compress Static Ext.||Configure IIS to Compress Dynamic Ext.||Configure ASP.Net Blob Cache|
|Static (html, css, doc, pdf…)||File System||Yes||No||No|
|Dynamic (aspx…)||File system||No||Yes||No|
|Static (html, css, doc, pdf…)||Content Database||No||Yes||Yes|
|Dynamic (aspx…)||Content Database||No||Yes||No|
Note: there is not use in activation compression for native MS Office 2007 format (docx, xlsx, pptx etc…) since they are already natively compressed, See Introducing the Office (2007) Open XML File Formats.
Content edited with SharePoint Designer can be compressed as long as the appropriate configuration is in place, regardless of their location.
Note: All the tests above were made on a standard WSS3 running on IIS6, it may behave differently on IIS7.
But who (the F or H, depending on your level of politeness) is Eugene Tooms then?
Eugene Victor Tooms is a fictional character appearing in two episodes of the TV series “The X-Files”. Tooms is able to squeeze and elongate his body in ways that are impossible for a normal human. This makes him similar to IIS in some ways 🙂