- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 1 Sep 1995 15:45:30 +0200 (MET DST)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: sjk@amazon.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter: >Caches may save any data, but documents with no Expires headers should >be treated in the same way that Expires yesterday: always be re-tested >with a GET if-modified-since. No they should not, re-resting is optional. The service author omits Expires at his own risk. > Caches can assume that servers that >supply data with an 'expires' date in the future didn't lie about the >expires date, whose interpretation is 'this data won't change until >the expires date'. No, the interpretation is not that the data will remain the same. The interpretation is that, even if the data changes, showing the old, but non-expired data is OK. >The expires date only applies to the URL which the data was fetched >*with* and not any other location information that might be supplied. I don't believe the spec says anything about the applicability of Expires to URLs in Location or URI headers. It should, though. My own intuition is that if a response contains an Expires header and an URI header, then the Expires date applies to all URLs in the URI header. How else is URI supposed to help caches simulate content negotiation? [...] >Taking this strict interpretation of caching will have only a minimal >impact on the performance of the net, I don't think so. It is safe to say that 99% of all current responses contains no Expires header. Your strict interpretation would make all of them uncacheable. The strict interpretation will only have a minimal effect once every server starts supporting conditional GETs. Koen.
Received on Friday, 1 September 1995 06:49:18 UTC