Should HTTP 304 Not Modified-responses contain cache-control headers?

In theory you shouldn't have to send Cache-Control for a 304 -- the recipient should just continue to use the cache directives that it received from the original 200. However, as you've found, in practice if you don't keep sending Cache-Control, browsers will ignore the cache directives that you sent originally, and revert to their own default heuristics So in practice, you should include the same Cache-Control with a 304 that you would with a 200. The spec only mandates that you send it for a 304 if it's different than what you sent previously (see 10.3.5 304 Not Modified ) -- but it certainly doesn't forbid you from repeating it when it's the same And to respond specifically to the wrong-headed points from the other answer (Structure's): You do want intermediary caches to cache the response (that is, update their cache entry for the resource).

They will respond appropriately to requests from clients with a 200 or a 304, depending on whether the client included a conditional header like If-Modified-Since The 120-second ttl will be refreshed by the 304 (so the same client shouldn't make another request for the same resource for at least another 120 seconds). And clients, as long as they've still got the content cached will continue to make conditional requests for the resource, which you can continue to respond to with a 304.

In theory you shouldn't have to send Cache-Control for a 304 -- the recipient should just continue to use the cache directives that it received from the original 200. However, as you've found, in practice if you don't keep sending Cache-Control, browsers will ignore the cache directives that you sent originally, and revert to their own default heuristics. So in practice, you should include the same Cache-Control with a 304 that you would with a 200.

The spec only mandates that you send it for a 304 if it's different than what you sent previously (see 10.3.5 304 Not Modified) -- but it certainly doesn't forbid you from repeating it when it's the same. And to respond specifically to the wrong-headed points from the other answer (Structure's): You do want intermediary caches to cache the response (that is, update their cache entry for the resource). They will respond appropriately to requests from clients with a 200 or a 304, depending on whether the client included a conditional header like If-Modified-Since.

The 120-second ttl will be refreshed by the 304 (so the same client shouldn't make another request for the same resource for at least another 120 seconds). And clients, as long as they've still got the content cached, will continue to make conditional requests for the resource, which you can continue to respond to with a 304.

If I understand correctly then the browser is in fact caching for 120 seconds and your server is responding 304 Not Modified to subsequent If-Modified-Since requests. This "IMS" request occurs when the end-user accesses the same URL. At that time the browser can send an If-Modified-Since request.

The browser wants to know if it is displaying stale content. This seems normal. Upon receiving this request your server should reply 200 OK, 304 Not Modified (or a 4XX, if necessary).

I do not believe you should set your server to send a Cache-Control header with the 304 response for two reasons: 1. You do not want any intermediary caches to cache that 304 response (there is a possibility that they could) 2. The 120 second TTL will not be refreshed by the 304 response.

The browser will retain the object for 120 seconds from the 200 OK response. After 120 seconds the browser should send a GET request, not an If-Modified-Since, so your server will respond with the bytes of the file and not just a 304 response. Note that the browser will not request the file again automatically after 120 seconds unless the end-user specifically requests it via a page load or directly inputting the URL into their address bar (or unless you have a custom application that controls that functionality somehow).

Edited the first paragraph to read a bit better(hopefully).

Hmmm, maybe a bit unclear from my side, but what I would like to achieve: 1) First request, set cache-control to cache at client for a period of time; max-age. 2) When the max-age is reached, the client should send a new request. 3) If content not changed on server, respond with 304.4) The browser should cache again for the max-age time.5) On further requests after max-age, get 304-response and renew the client cache.

Now, after the inital 200 and max-age, it "loops" on sending requests to server with 304 as response. Then again, maybe what I would like to achieve isn't a valid approach? – runarM Oct 19 '09 at 10:56 Here is my take: 1) First request, 200 OK, Cache-Control set via max-age.2) If the client makes a subsequent request after the file is stale, it should make a GET request.

Otherwise, an IMS request.3) If GET request, 200 OK. If IMS, 304 Not Modified or 200 OK.4) Re-cache file, or retain current copy until max-age is expired and it is requested again, in which case go to #1 above.5) There is no #5. :) If your goal is to have the end-user keep the file as long as possible and only use 304 responses (and you will not update the file) then I suggest a much longer max-age.

– Structure Oct 19 '09 at 12:31 To add to my last comment. I see nothing in the RFC that says your method will not work, or is not valid. However, the wording suggests it is not intended to work that way.

The "request" in the RFC suggests a GET request. A 304 is returned in response to an If-Modified-Since request, which is used to validate cache. There is no indication that a Cache-Control header can be included in a 304 response in order to update the headers of a file that is currently in cache.It suggests Cache-Control headers are normally set with the response to a standard GET request.

– Structure Oct 19 '09 at 12:41 If that answered your question then go ahead and mark it as answered. If not then I or someone else will take a stab at clarifying. – Structure Oct 20 '09 at 0:36 Im still not sure whether its an recommended approach to set the cache-control headers with the 304 response.

Ive found examples suggesting this is valid, and the spec isn't very clear on the matter. I'm hoping that someone has some experience in favor of on or the other theory. All my testing so far does, however, indicate that this will work just fine, but then there are a lot of different scenarios to consider.

– runarM Oct 20 '09 at 9:39.

HTTPbis updates RFC2616 to say: A 304 response MUST include a Date header field (Section 9.3 of Part1) unless its omission is required by Section 9.3.1 of Part1. If a 200 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires, Last-Modified, or Vary, then those same header fields MUST be sent in a 304 response.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.