W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

some comments on HTTP/1.1 spec (03)

From: Shel Kaphan <sjk@amazon.com>
Date: Sun, 19 May 1996 15:52:38 -0700 (PDT)
Message-Id: <199605192252.PAA24996@bert.amazon.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

I'd like to suggest that the second paragraph of 16.2.2 (Limitations
on the effect of Expiration Times) be moved to 16.11 (History Lists),
and that a short cross reference to 16.11  be put in 16.2.2 instead.
I'd also like to see the "should" in the third sentence of that
paragraph be in upper case so that it is clear this is intended in the
formal sense.

Then, I think 16.11 needs one more paragraph to explain the reason
behind the suggestions about history lists, because this is something
that has proven to be a stumbling block for browser implementers in
the past, and if they continue to make mistakes with this, it may
render much of the new cache-control stuff moot for many applications.
Perhaps something like this:

"Furthermore, if history list mechanisms unnecessarily prevent users
from viewing stale resources, this will tend to force service authors
to avoid using HTTP expiration controls and cache controls when they
would otherwise like to.  Service authors may consider it important
that users not be presented with error messages or warning messages
when they use navigation controls (such as BACK) to view previously
fetched resources.  Even though sometimes such resources
ought not to cached, or ought to expire quickly, user interface
considerations may force service authors to resort to other means of
preventing caching (e.g. "once-only" URLs) in order not to suffer the
effects of improperly functioning history mechanisms."

	---------------------------

In 16.9 (Invalidation after Updates and Deletions), last sentence, it
should be made clear which resource is to be invalidated if
Content-Location and/or Location are present as well as the request-URI.

Regarding invalidation, it would also be nice to put in a little
caveat to the effect that that a single logical site that operates
across multiple hosts may work improperly if the URLs are not
partitioned carefully across these hosts (because operations on one
host cannot invalidate cache entries from another host), and also that
there is a similar problem if the communication path from client to
origin server varies with time during a user's interaction with that
origin server, and they end up going through multiple
non-communicating caches.

I would also like to see references to 16.9 in sections 18.15
(Content-location) and 18.27 (Location), since invalidation is an important
part of the logic for handling both of these headers.

	---------------------------

18.5 (Age) and 16.2.4 should explicitly reference each other, and
16.2.4 should be a little more explicit about what goes into the Age
header that is transmitted by an intermediate cache.  Furthermore, 
I think the discussion needs a sentence or two of motivation
about the problem that Age is intended to resolve, as to why it is
insufficiently addressed by simply doing a computation based on Date.


More later, probably.

--Shel Kaphan
  sjk@amazon.com
Received on Sunday, 19 May 1996 15:53:39 EDT

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