[Webkit-unassigned] [Bug 17998] WebKit seems to ignore Expire / ETag headers nullifying cache

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Mar 22 15:02:20 PDT 2008


http://bugs.webkit.org/show_bug.cgi?id=17998





------- Comment #2 from mark.hughes at green-ant.com  2008-03-22 15:02 PDT -------
(In reply to comment #1)
> Please try a similar experiment but instead of hitting Reload, simply load the
> page again by hitting Enter in the address bar.

On resubmission, or by following a link to that page, the cache is wholly
respected and there is not even a request to validate the content to confirm
the page's status - there is no network activity whatsoever. This is great, and
even more "aggressive" than other browsers.

However, why during a reload are the linked resources themselves not trusted? I
could see a reload causing the contents of the "primary" URL to be forceably
reloaded/reverifed (Cache-Control: max-age=0), but if that page references
resources in the cache already, wouldn't it be more sensible/efficient to let
the cache work the same way as if you had reentered the URL? In this case, with
Expires/Cache-control: max-age=>0 (freshness) and ETag (validator) returned in
the initial response, sending the If-None-Match / If-Modified-Since headers
would make the utmost sense.

In short, even if reload becomes a condition for the browser to forceably
revalidate all of the resources involved, shouldn't the proper outcome of
described scenario be a stream of 304s from the server in the ideal situation?


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list