views:

568

answers:

1

Two-part question (parts are closely related): with the default OOTB ETag policy that IIS7 employs, why don't we see the If-None-Match/304 interaction as we navigate through pages?

The headers returned for an empty-cache request, for instance, are:

Content-Type    image/png
Last-Modified   Thu, 03 Dec 2009 15:51:56 GMT
Accept-Ranges   bytes
Etag    "a8a0628a3074ca1:0"
Server  Microsoft-IIS/7.0
X-Powered-By    ASP.NET
Date    Tue, 22 Dec 2009 19:47:36 GMT
Content-Length  1780

...and yet subsequent accesses to the page don't generate a 304 round-trip for the image?

Also, the default applicationHost file for IIS7 has the following (1):

   <caching enabled="true" enableKernelCache="true">
   </caching>

Does enableKernelCache='true' extend to all static files, freeing you of the need to register extensions explicitly to grant CacheUntilChange as the kernel policy (2):

<caching>
  <profiles>
    <add extension=".gif" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" />
    <add extension=".png" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" />
    <add extension=".js" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" />
    <add extension=".css" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" />
    <add extension=".jpg" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" />
    <add extension=".jpeg" policy="DontCache" kernelCachePolicy="CacheUntilChange" duration="0.00:01:00" location="Any" />
  </profiles>
</caching>

(1) %systemroot%\System32\inetsrv\config\applicationHost.config

(2) http://labs.episerver.com/en/Blogs/Per/Archive/2009/3/Configuring-cache-expiration-on-IIS-7/

+1  A: 

The handling of ETags and the associated If-None-Match / If-Modified-Since is somewhat browser dependent. You might try a few different browsers and see what happens -- in general, if you don't set an explicit expiration time, I would expect to see the 304's, as you said.

For kernel caching, it is enabled for static files by default. To help see what's happening, I've found it helpful to run the following command:

netsh http show cachestate

That will show information about the files that are currently in the cache.

Keep in mind that files normally have to be referenced a couple of times within a certain time window before the kernel will cache them.

RickNZ
Thanks, Rick; I've tried both IE8 and FF 3.5 and find this behavior a bit strange - is it documented anywhere? IIS7 (OOTB) doesn't issue expiration headers, just the ETag; and yet subsequent requests to the page don't generate 304s for these objects?
Nariman
The only documentation I'm aware of is the HTTP specification. I wonder if you're seeing a per-session optimization. Have you tried exiting the browser (all windows), restarting, and seeing if that results in 304s? Is there a public page I can see that exhibits the behavior you're describing?
RickNZ
Since the original responses don't have a Cache-Control header, the browser is (somewhat) free to implement its own policy regarding caching. In this case, it chooses to cache the images for the duration of the session. If you close the tab in IE8 with your site in it, and then open a new tab and go back to the same page, you will see a bunch of IMS/INM requests and 304 reponses for all of the images.
RickNZ
Interestingly, in FF3.5.7, even in new sessions the request isn't made. I'd be curious to know what they're default setting ("Check for a new version when the page is out of date") actually means with respect to ETag responses (http://kb.mozillazine.org/Browser.cache.check_doc_frequency).
Nariman