W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Location Proposals

From: Koen Holtman <koen@win.tue.nl>
Date: Sun, 3 Sep 1995 00:56:08 +0200 (MET DST)
Message-Id: <199509022256.AAA07064@wswiop05.win.tue.nl>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:31 EDT