Last post Dec 13, 2011 08:56 AM by ojm37
Nov 04, 2011 10:31 AM|ojm37|LINK
IIS 7.5 (not sure if 7.0 has the issue) caches static files for a short time period (about 1 to 2 seconds) and includes ALL HEADER information in the cache. So if, for example, you have an httpModule configured that sets a cookie, that cookie will be set
for all requests of the static file until the cache expires.
So, the question is: How do I tell in my httpModule if the file is static (image, js, etc) (without resorting to looking at the file extension)? I would like to not set cookies -- or any other header data, for that matter -- if the file is static (and will
be cached by IIS 7.5).
Nov 14, 2011 10:47 PM|rstrahl|LINK
I doubt this has anything to do with what IIS does, and all to do with what your browser does. Static files are served with caching headers by default by IIS so an Http GET SHOULD actually cache that content unless the underlying file changes. If you look
at the headers for static files you should find cache headers, last-modified headers and ETag headers all of which deal with caching of content as long as the underlying file doesn't change.
When in doubt do a forced browser refresh (Shift-f5) and see what happens... it should fully reload at that point...
+++ Rick ---
Nov 15, 2011 09:16 AM|ojm37|LINK
Actually, it has EVERYTHING to do with what IIS 7.5 does and NOTHING to do with the browser! I opened a ticket with Microsoft to solve the problem. Turning off SERVER side (and kernel mode) caching puts a band-aide on the problem by telling IIS not to cache
any static files. This, of course, is not acceptible due to performance issues. So, I was able to stop the problem by only setting the particular cookie when an aspx file is being processed. That way, I don't have to go through a list of "static" files and
not set the cookie for them.
In summary, STATIC files (graphics, css, js, etc), in INTEGRATED mode go through any httpModule(s) that is(are) specified in web.config. If you set a cookie in your httpModule, static files (that IIS determines need to be cached) will have the cookie cached
along with the file data. So, the next user who requests that file (as long as it is in the SERVER cache) will receive the cached version, INCLUDING COOKIES and other header information.
A tricky part in diagnosing what was happening is that IIS does not immediately cache all static files: only the ones it determines (by usage frequency) need to be cached. Then that cache is very short (on the order of seconds). This is a true SERVER-SIDE
cache and does not involve the browser. So, for example, if you have 10 users requesting a static file in quick succession, IIS will at some point decide that the static file needs to be cached. At that point, the next N users (until the cache expires) will
receive the static file from server memory (including headers) instead of IIS retrieving the file from disk and running the httpModule. Once the cache expires, the remaining users will recieve the file from disk again until IIS decides it needs to be cached.
So, the SERVER "cached" static file is sent to the browser with response code 200! Not response code 304 (meaning browser-cached)!
--Hope that makes sense. It sure didn't for a few days to me...
Dec 13, 2011 08:52 AM|raimond|LINK
Do you already have a solution for this problem?
Dec 13, 2011 08:56 AM|ojm37|LINK
I ended up having to check the file-type before setting a cookie. Instead of checking for all the file-types where I don't want to set the cookie (gif, jpg, png, doc, etc), I check for the file-types where I want to set the cookie (turns out to be only
asp and aspx).
Still seems a little goofy to me that there isn't an easy indicator in code that the file is static or active (since the httpModule runs every time regardless of that type, making static files active - by definition because code runs).