No files in the “IIS Temporary Compressed Files” directory. Some possible reasons.
I had a case were no files were stored (or missing) in the “IIS Temporary Compressed Files” directory.
During research, I noticed that there were a few things to look for/think about when you see no compressed files in the ”IIS Temporary Compressed Files” directory.
So here is a short list.
.1 Make sure it is enabled on the IIS side.
Rightclick the “Web Sites” folder, select properties, select the Service tab and make sure the Compress Application files
and “Compress static files” are checked (depending on what you want to compress of course).
.2 Make sure you are looking in the correct directory.
Again, in the same location as above, make sure that the path to where to save the compressed files is not different to what you expect.
The default location is:
C:\WINDOWS\IIS Temporary Compressed Files
so if you look there and the path is different in the properties, then of course you will not see the files.
3. You are not accessing static files.
In short, static files are compressed on first access and then saved to the location in #2.
If the files are dynamic, they are compressed but on-the-fly. In other words, they will be compressed on every access and streamed to client.
Nothing will be saved on disk.
This can easily be seen. Create a new file in your website, call it “Demo.html“, enter the following code:
<HTML>
<BODY>
<FORM>
Demo of dynamic vs. static compressed files.
</FORM>
</BODY>
</HTML>
and access it from a client. This should produce the following compressed file (if default directory is used.):
C:\WINDOWS\IIS Temporary Compressed Files\$^_gzip_C^^INETPUB^WWWROOT^COMPRESS^DEMO.HTML
Delete this file, and change the extension from .html to .asp and access it again.
This time there will be nothing stored on disk since the Asp page is built dynamically. See more on this here:
"Using HTTP Compression for Faster Downloads (IIS 6.0)"
.4 The application pool used by the website do not have correct Access Permissions on the default directory where the compressed files are stored.
In short, if you are running the web site with an application pool that runs with an identity that do not have permissions to use
the “C:\WINDOWS\IIS Temporary Compressed Files” directory (if using default) then the HTML will be returned to the client, yes.
However, the compressed file cannot be written to disk because access is denied.
You can download the Process Monitor tool:
"Process Monitor"
https://technet.microsoft.com/en-us/sysinternals/bb896645
Run it on the IIS side and access the page. Then you can search for access denied. Using the Demo.html from earlier I will get the following output:
w3wp.exe CreateFile C:\WINDOWS\IIS Temporary Compressed Files\$^_gzip_C^^INETPUB^WWWROOT^COMPRESS^DEMO.HTML7856~TMP~ ACCESS DENIED NT AUTHORITY\NETWORK SERVICE
So here it is clear that the file can’t be created since NT AUTHORITY\NETWORK SERVICE gets an Access Denied.
.5 You do not request compression from the client side.
In short, if the request from the client is made using HTTP 1.0 the “Accept-Encoding” header will not be part of the request.
If “Accept-Encoding” is not part of the request then of course there will be no instruction to create a compressed file, see for example:
https://en.wikipedia.org/wiki/Accept-Encoding
"If Internet Explorer (tested up to version 8) is set to use HTTP/1.0 rather than HTTP/1.1, it will not send an Accept-Encoding: header.
It will, as a result, ignore any Content-Encoding headers that it sees, and will not decompress compressed content.
Enabling HTTP/1.1 in Internet Explorer sends the Accept-Encoding: header, and decompresses the response correctly."
You can see this by downloading the Fiddler tool:
"Fiddler2"
https://www.fiddler2.com/fiddler2/version.asp
Install it on the client and access the Demo.html file (delete the compressed file before doing this).
Then check the Fiddler trace (example below is from the Raw tab for the Request).
When using HTTP 1.1:
GET https://<your URL>/Demo.html HTTP/1.1
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; ...
Accept-Encoding: gzip, deflate, peerdist
If-Modified-Since: Mon, 07 Mar 2011 12:08:21 GMT
If-None-Match: "adb53c5ac0dccb1:44a"
Connection: Keep-Alive
Host: <your server>
X-P2P-PeerDist: Version=1.0
When using HTTP 1.0 (you can do this by unchecking the “Use HTTP 1.1” under the Advanced tab in the internet options for IE):
GET https://<your URL>/Demo.html HTTP/1.0
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; ...
Connection: Keep-Alive
Pragma: no-cache
Host: <your server>
X-P2P-PeerDist: Version=1.0
Accept-Encoding: peerdist
So here it shows that when 1.0 is used, no Accept-Encoding is sent and no compression is used.
So make sure HTTP 1.1 is used, otherwise no compression is instantiated on IIS.