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: Fri, 1 Sep 1995 15:45:30 +0200 (MET DST)
Message-Id: <199509011345.PAA06625@wswiop05.win.tue.nl>
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.

Received on Friday, 1 September 1995 06:49:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC