Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a strange issue with IIS 7.
Sometimes it seems to return a 304 instead of a 200.

Here is a sample request captured with Fiddler:
(Note that the file requested is not located in my browsers cache yet.)

GET https://[mysite]/Content/js/jquery.form.js HTTP/1.1
Accept: */*
Referer: https://[mysite]/Welcome/News
Accept-Language: sv-SE
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: [mysite]
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: ...

Note that there is no If-Modified-Since or If-None-Match in the request.
But still the response is:

HTTP/1.1 304 Not Modified
Cache-Control: public
Expires: Tue, 02 Mar 2010 06:26:08 GMT
Last-Modified: Mon, 22 Feb 2010 21:58:44 GMT
ETag: "1CAB40A337D4200"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 01 Mar 2010 17:06:34 GMT

Does anyone have a clue of what could be wrong here?

I'm running IIS 7 on Windows Web Server 2008 R2.


I've found a workaround, enable caching and then disable it on an extension level did the trick for me.

    <caching enabled="true" enableKernelCache="true">
        <add extension=".png" policy="DisableCache" kernelCachePolicy="DisableCache" />
        <add extension=".gif" policy="DisableCache" kernelCachePolicy="DisableCache" />
        <add extension=".js" policy="DisableCache" kernelCachePolicy="DisableCache" />
        <add extension=".css" policy="DisableCache" kernelCachePolicy="DisableCache" />
      <clientCache cacheControlMode="NoControl" />
share|improve this question
I'm having the EXACT same issue, and it's causing a lot of problems on a very busy web server. IIS returns a 304, even though the client doesn't yet have a copy of the resource. – Philippe Leybaert Apr 28 '10 at 13:05
@Philippe, have you found a solution yet? Otherwise see my edit above for an workaround and checkout the new answer below. – Ola Herrdahl Jun 4 '10 at 13:12
@OlaHerrdahl, your workaround is perfect :) I had this exact issue as well. Thanks! – Ardee Aram Aug 21 '12 at 2:51

According to section 14.9 of the HTTP1.1 spec, the no-cache directive for the Cache-Control header is only imposable by the origin server, which means IIS is ignoring the header in your request.

The cache-control directives can be broken down into these general categories:

  - Restrictions on what are cacheable; these may only be imposed

by the origin server.

Section 14.9.1 defines public, private, and no-cache as the directives restricting what is cacheable, which can only be imposed by the server.

If you don't want your .js file to be cached you'll either need to set the no-cache directive in the app (ie- the ASP.NET code) or you'll need to change the Cache-Control header in the request to use the no-store directive instead of no-cache.

Based on your comment - yes I assumed you did not want the file cached. The 304, then, might be coming as a result of the file being in one of IIS's internal caches. Have a look at these:

share|improve this answer
I think you misunderstood my problem here. The file is not located in my cache yet. But still the server replies with a 304... This seems to happen randomly when browsing the site in all major browsers. – Ola Herrdahl Mar 1 '10 at 18:45
@Ola Herrdahl: Have a look at my edit. – squillman Mar 1 '10 at 19:15
I have tried disabling caching in IIS as well and it makes no difference... :( – Ola Herrdahl Mar 2 '10 at 8:21

I have been having the same problem for a while and have all caching turned off... However, I installed the Compression module for IIS7 at some point which by default had enabled compression of static files on my existing sites. I turned all compression off for the impacted sites and now they seems to be working fine touch wood.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.