Bug 52821 - Etag = "" (empty string) forces Chrome and Safari to ignore Cache-Control and never use cache
Summary: Etag = "" (empty string) forces Chrome and Safari to ignore Cache-Control and...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-20 10:17 PST by stevethimmesch
Modified: 2018-03-21 03:47 PDT (History)
6 users (show)

See Also:


Attachments
Fiddler Log with etag = "" (139.54 KB, application/x-zip-compressed)
2011-01-21 13:36 PST, stevethimmesch
no flags Details
Fiddler Log with iis6 generated etag (13.95 KB, application/x-zip-compressed)
2011-01-21 13:37 PST, stevethimmesch
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description stevethimmesch 2011-01-20 10:17:30 PST
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.
Comment 1 Alexey Proskuryakov 2011-01-20 14:05:58 PST
Darin, does chromium network back-end support ETags, or is this purely a WebCore memory cache issue?
Comment 2 Darin Fisher (:fishd, Google) 2011-01-20 14:25:52 PST
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.)
Comment 3 stevethimmesch 2011-01-21 13:36:35 PST
Created attachment 79781 [details]
Fiddler Log with etag = ""
Comment 4 stevethimmesch 2011-01-21 13:37:22 PST
Created attachment 79782 [details]
Fiddler Log with iis6 generated etag
Comment 5 stevethimmesch 2011-01-21 13:50:15 PST
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' :).
Comment 6 rvargas 2011-01-24 17:03:31 PST
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?
Comment 7 Alexey Proskuryakov 2011-07-14 13:09:59 PDT
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?
Comment 8 Alexey Proskuryakov 2011-07-14 13:19:03 PDT
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.
Comment 9 stevethimmesch 2011-07-14 13:37:00 PDT
(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.
Comment 10 Alexey Proskuryakov 2011-07-14 15:01:48 PDT
> 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.