Bug 52821 – Etag = "" (empty string) forces Chrome and Safari to ignore Cache-Control and never use cache

• Component: Page Loading
• Status: UNCONFIRMED

We use IIS6 and set the Etag = "" to (attempt to) disable etags and stricly use Cache-Control (max age).  This works fine in IE, Opera and FireFox.  Unfortunately, in Chrome and Safari it never caches the file and always requests it again from the server.

[Alexey Proskuryakov]

Darin, does chromium network back-end support ETags, or is this purely a WebCore memory cache issue?

[Darin Fisher (:fishd, Google)]

The Chromium network stack supports ETags.

It would be very helpful to see the actual HTTP response headers sent by this server.  Is there an URL to this site that we can load to reproduce the problem, or can you attach a copy of the response headers captured using WireShark or some other tool?

(In Chrome, you can use about:net-internals to view response headers and other network related info.)

Created attachment 79781 [details]
Fiddler Log with etag = ""

Created attachment 79782 [details]
Fiddler Log with iis6 generated etag

I attached some fiddler logs generated from chrome.  When the etag is "" it never uses the cache.  When it has a generated etag it will use the cache correctly.  What we were trying to do was disable IIS6 from generating etags by setting the etag to "".  It seems when other browsers get an empty etag they ignore the etag and use the max-age.  Honestly, I'm not sure what browser is actually behaving 'correctly' :).

I don't see any problem here.

This is part of the request that results in a 304:

Host: qa40.fnismls.com
Connection: keep-alive
Cache-Control: max-age=0
If-Modified-Since: Fri, 21 Jan 2011 19:57:42 GMT
Accept: text/css,*/*;q=0.1
If-None-Match: "ae34d476a5b9cb1:0"

And this is part of the request that results in a 200:

Host: qa30.fnismls.com
Connection: keep-alive
Cache-Control: max-age=0
If-Modified-Since: Tue, 04 Jan 2011 20:43:39 GMT
Accept: text/css,*/*;q=0.1
If-None-Match: ""

So in both cases we have a cached resource and we are validating it with the server. However, the server doesn't like the second request.

Maybe I'm wrong, but as far as I can tell, ETag: "" is a perfectly valid ETag. Maybe using a constant (not empty) string does that you want?

[Alexey Proskuryakov]

I'm testing this with Safari 5.0.5 on Windows 7 now. 

The bug report says "PC/Mac OS X 10.5". Are you seeing this only on Windows, or also on Mac? The attached Fiddler log is from Windows.

I can reproduce this, but I only see that after restarting Safari. If I make a new tab and open the same page in it, resources with empty ETag are loaded from cache just fine.

Could you please confirm that this is what you are seeing?

[Alexey Proskuryakov]

I forgot to mention that I cannot reproduce this on Mac OS X 10.6.8 with Safari 5.0.5 - I can only reproduce on Windows.

(In reply to comment #8)
> I forgot to mention that I cannot reproduce this on Mac OS X 10.6.8 with Safari 5.0.5 - I can only reproduce on Windows.

Thanks for following up.  I have never attempted a tested on the MAC OS X platform.  We have since worked around the problem by avoiding the etag = "" setting.

[Alexey Proskuryakov]

> I can reproduce this

I take that back. I had an incorrect mix of WebKit and Safari versions - and when I made a clean install, this stopped happening.