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

Re: Location Proposals

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 1 Sep 95 09:46:43 PDT
Message-Id: <9509011749.AA08551@netmail2.microsoft.com>
To: http-wg-request%cuckoo.hpl.hp.com@hplb.hpl.hp.com, masinter@parc.xerox.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, sjk@amazon.com
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.  If indeed 99% of all current servers don't send 
Expires, all the more reason to re-test and not just blithely serve up 
a stale page.

Or are you proposing that only the presence of Pragma: no-cache would 
cause a re-test each time?

] > 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.

I agree with Koen here, although I think of "same" as meaning the same 
thing in the context of HTTP -- i.e., my definition of the same is not 
"memcmp(x,y) == 0" but "functionally equivalent ( as far as the client 
and sever are concerned)" in order to avoid quibbles about things 
changing that no-one cares about -- and the more accurate phrase is too 
long to type each time. I think I'll use "equivalent" in the future, 
though, rather than "same", just to avoid the problem.

] >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.

No, I think it means they can only be served out of the cache after 
doing a GET I-M-S.

] The strict interpretation will only have a minimal effect
] once every server starts supporting conditional GETs.

I think you must have in mind some heuristics that current caches use 
to impute reasonable Expires or other equivalent cache control info for 
servers that don't provide any.  Without knowing those, I can't 
evaluate the impact of your interepretation of how caches should handle 
no Expires, 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.

Received on Friday, 1 September 1995 10:37:51 UTC

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