My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 64139: Cache isn't revalidated properly, no-cache directive
8 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Closed:  Dec 2010

  • Only users with Commit permission may comment.

Sign in to add a comment
Reported by AmbiWeb, Nov 22, 2010
Chrome Version       : 7.0.517.44
Other browsers tested: OK

What steps will reproduce the problem?

1. Send Response Headers containing
Etag	e9b54d850e24a0316bcb42fac75204ef
Expires	Mon, 22 Nov 2010 23:37:12 GMT
Last-Modified	Mon, 22 Nov 2010 22:37:12 GMT
Cache-Control	private, must-revalidate, no-cache
2. Refresh the page
3. Check the request and response headers.

What is the expected result?

The expected result is that chrome sends a request to the server using the following lines in the header:

If-Modified-Since	Mon, 22 Nov 2010 22:37:12 GMT
If-None-Match	e9b54d850e24a0316bcb42fac75204ef

That request would lead to a 200 or a 304 depending on possible content-changes. Chrome should get the content from its cache when a 304 is delivered. Chrome should show the new content when a 200 is delivered. The idea of the no-cache directive is to send 304 statuscodes to reduce bandwidth whenever possible and to send 200 statuscodes to force freshness. The revalidation therefore must be done on every request.

What happens instead?

Chrome does not perform any request to the origin-server. Chrome gets the page out of the cache until the expirationdate is reached or a page reload is forced.

Why is chromes behaviour wrong?

I just want to quote the no-cache directive from section 14.9.1 of :

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
Nov 22, 2010
Thanks for the report.

However, I'm not able to repro. Could you navigate to about:net-internals before fetching the page that you are using for testing and attach the relevant request from the "events" tab? What is stored by the cache (you can see all entries on the "http cache" tab)?
Labels: -Area-Undefined Area-Internals Internals-Network
Nov 22, 2010
#2 AmbiWeb
Hi! I extracted 4 requests and seperated them with a line of dashes. The file is attached. As you can see the first request is fine. The second request has problems with the response headers (Cache-Control) and the other requests are delivered from cache.
12.4 KB   View   Download
Nov 22, 2010
Thanks for the trace.

It looks like the problem is that the second response from the server (the 304) is adding an empty Cache-Control header, basically erasing the previous directive.

If you look at the cached entry you should see an empty Cache-Control header.
Nov 23, 2010
#4 AmbiWeb
Ok. I looked deeper into this. The response from the Server is something similar to this.

HTTP/1.1 304 Not Modified
Date: Tue, 23 Nov 2010 09:06:32 GMT
Server: Apache/2.2.16
Connection: close
Etag: 0dc542d86ac6b81c4be0c5f81cc45d5a
Expires: Tue, 23 Nov 2010 10:03:23 GMT

The server does not send a Cache-Control or Last-Modified in the header. It does send an Etag and Expires.

So the problem is that chrome is asked to update the headers but it does not continue to use the Cache-Control header submitted in the first request. Instead chrome interprets the missing Cache-Control as an empty Cache-Control.

I would expect Chrome to keep all existing headers and update only informations that has changed with the 304 headers. Cause thats exactly what a 304 is about (not modified).
Nov 23, 2010
The log you updated contains an empty Cache-control:

t=1290476563023 [st=221]           HTTP_TRANSACTION_READ_RESPONSE_HEADERS  
                                   --> HTTP/1.1 304 Not Modified  
                                       Date: Tue, 23 Nov 2010 01:42:42 GMT
                                       Server: Apache/2.2.16      
                                       Connection: close          
                                       Etag: afb9820232b196800fcd0b6991f727ee
                                       Expires: Wed, 24 Nov 2010 01:42:37 GMT
t=1290476563023 [st=221]       -HTTP_TRANSACTION_READ_HEADERS

Are you saying that Cache-Control is not part of the response from the server? Can you confirm that with a network trace (fiddler or similar)?

Nov 23, 2010
#7 AmbiWeb
Shame on me. I just doublechecked and it seems that there is really an empty Cache-Control field. However it seems that Firefox & Co can handle that and drop empty fields. Chrome updates the field.
Nov 23, 2010
#8 AmbiWeb
BTW.: If you use PHP for your site and start a session PHP sets a predefined headerset for you. The headerset contains Pragma and Cache-Control. If you don't want to use the predefined policies you can only set the fields to an empty value. In PHP 5.3 header_remove was introduced. 

The problem with all this is that you're not really in charge of your headers in PHP before PHP 5.3 in combination with sessions. If you try to implement efficient caching you run into problems like this.

Dec 8, 2010
Our implementation follows the HTTP spec (section 13.5.3):

      - any end-to-end headers provided in the 304 or 206 response MUST
        replace the corresponding headers from the cache entry.
Status: WontFix
Apr 4, 2011
When will this bug be fixed? Even IE respects the must-revalidate
Apr 5, 2011
#11 AmbiWeb
This bug won't be fixed because it is no chome-bug. As I described it is related to php and sessions and the scenario is obsolete in php 5.3 which is the only supported php-version right now.
May 9, 2012
HTTP Spec (section 13.5.3) also says the following:
   Note: this rule allows an origin server to use a 304 (Not
      Modified) or a 206 (Partial Content) response to update any header
      associated with a previous response for the same entity or sub-
      ranges thereof, although it might not always be meaningful or
      correct to do so. This rule does not allow an origin server to use
      a 304 (Not Modified) or a 206 (Partial Content) response to
      entirely delete a header that it had provided with a previous

Note the part about not allowing to "entirely delete a header". That is effectively what chrome is doing.
May 9, 2012
It seems like not having a Cache-Control header also clears it?
Oct 13, 2012
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
Sign in to add a comment

Powered by Google Project Hosting