- From: Koen Holtman <koen@win.tue.nl>
- Date: Sun, 3 Sep 1995 00:56:08 +0200 (MET DST)
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, Koen Holtman <koen@win.tue.nl>
Paul Leach: >Koen said: >] 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. > >I agree with Larry. A good cache should re-test (via GET I-M-S) if no >Expires is present. A good cache should *occasionally* (the interval depending on heuristics based on the Last-Modified header or somesuch) re-test. I was talking about what every cache is *required* to do. I don't want to require caches to send with conditional GETs *all* the time. This would be bad for web access speed (round-trip times) at least. Sending conditional GETs all the time might even take a serious amount of bandwidth (think inline pictures!). [...] >] It is safe to say that 99% of all current responses >] contains no Expires header. Your strict interpretation would make all of >] them uncacheable. > >No, I think it means they can only be served out of the cache after >doing a GET I-M-S. We have a terminology problem here. In my book (and, I believe, in the spec), a page that can only be served out of the cache after doing a GET I-M-S is called `uncacheable'. I have proposed the term `conditionally cacheable' for `can be served after doing a conditional GET (GET I-M-S)'. Note that *all* GET requests are conditionally cacheable. >] The strict interpretation will only have a minimal effect >] once every server starts supporting conditional GETs. I've looked a bit into the current conditional GET situation, and it seems that most servers support it already on normal documents, so I retract part of my above statement. The only non-minimal effect of the strict interpretation (which is to always send a conditional GET if no Expires was present) will be on URLs driven by CGI scripts. >[...] except to think that you're saying its OK to serve up 99% >of all servers' pages out of the cache, unconditionally, no matter how >old the page is. I'm not saying it would be OK, I'd consider a cache that keeps a document without Expires (pragma, cache-control) cached for 200 days without ever rechecking it broken. But I don't want to consider such a cache non-conformant to the spec. In the end, it is the responsibility of the service author to put Expires (pragma, cache-control) headers on pages that can become stale. The cache author has no obligation to spend time implementing heuristics to correctly handle dynamic pages made by authors too lazy to include these headers. Of course, most cache authors _will_ spend time implementing such heuristics, but that is another matter. >Paul Koen.
Received on Saturday, 2 September 1995 15:57:36 UTC