W3C home > Mailing lists > Public > public-bpwg@w3.org > July 2008

ACTION-793 Work with Scott to produce proposed text on caching that goes beyond BP 1

From: Scheppe, Kai-Dietrich <k.scheppe@telekom.de>
Date: Thu, 24 Jul 2008 17:16:39 +0200
Message-ID: <398533C370C23441981074C456AA3BDD031DB8AF@QEO00226.de.t-online.corp>
To: <public-bpwg@w3.org>
I just realized I already have some further test results I can pass
The text I had sent to Scott originally had basically centered around
- a valid expires header
- a must-revalidate header
- a setting of M (modification) in the Webserver, making the expires
period dependent on the last-modified time stamp of the resource
All together were supposed to instruct the browser and proxies to make a
head request and load the resource only when it has been modified.
This setup did not produce reliable results.
Further tests showed that instead of "must-revalidate" what should be
used is
- proxy-revalidate
- no-cache
Proxy revalidate specifically instructs proxy caches to revalidate the
no-cache, contrary to what most people tend to think, mean that it
causes the browser to make a head request every time.
We found only one odd behavior:  IE ignores the header when no proxy is
specified and always pulls a resource.
FF, Opera and IE (with proxy configured): 
 - a fresh resource = 304 not modified return code
 - a stale resource = 200 return code, with subsequent 304 on a renewed
IE (without proxy configured)
 - a fresh resource = 200 return code
 - a stale resource = 200 return code
Nevertheless, this ensures that modification-based caching delivers a
fresh resource only when the resource has been modified.
Interesting side effect:   The expires header seem to have lost
After the expires period has passed, max-age turns negative and 304
continues to be returned until there is change in the last-modified time
stamp of the resource, at which point the expires period is applied
However, passing the expires period does not cause a request for the
-- Kai
Received on Thursday, 24 July 2008 15:17:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:52 UTC