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

I just realized I already have some further test results I can pass
on....
 
 
 
The text I had sent to Scott originally had basically centered around
using
 
- 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
resource. 
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.
 
 
Results:
 
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
request
 
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
importance.  
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
again.
However, passing the expires period does not cause a request for the
resource.
 
 
 
-- Kai