list of pending proposals

The following is a list of minor proposals for HTTP 1.1 that I have
made or implied, or have heard and would simply like to reaffirm.  In
most cases I have no idea what the consensus is, if any.  I would like
to somehow come to decisions on these things (How does http-wg make
decisions?), or at least to finish the discussion in some more
satisfactory way.  I exclude rationale for these proposals since they
have almost all been discussed to some extent previously.

1. 2xx responses containing Location headers should cause caches, when
possible, to invalidate entries keyed by the URI given in the Location
header.  (This is to help stamp out evil doppelgangers).

2. Proxies should be allowed to forward requests for methods that they
do not understand, instead of being required to return 501.

3. New request header "Cache-control: serve-from-cache".  Allows
requests for private "extension methods" to be served from a cache
without being forwarded to origin server (similarly to GET and
HEAD). Overrides Cache-control: no-cache on requests.

4. Cache-control: max-age=nnn  cannot appear in same response as 
Expires: <date>.  If both appear, the Cache-control wins.

5. Cache-control: no-cache cannot appear in same response as
Expires: <date>.  If both appear, the Cache-control wins.

6. Effect of "Cache-control: no-cache" on history mechanisms should be
defined.  It should either force history mechanisms to reload a page
whenever it is visited, or it should explicitly not interact with
history mechanisms, as with Expires.  It needs to be defined to be the
same thing for all User Agents.

7. Roy already more-or-less said this was going into the spec, I
think, but I just want to reaffirm: When the URI header is present in
a response containing an entity (a 2xx response), the Location header
MUST always be present to identify which of the variants is being
returned.  When the URI header is present in a redirection response
(3xx), the Location header MUST always be present to indicate a
default for redirection.

8. Due to potential security problems, the URI's returned in Location
and URI response headers should never be used as cache keys.  Only the
request-URI should be used as a cache key.  (This does open up a
potential discussion about how the other type attributes returned in
responses are to be used to control caching, but I don't want to get
into that right now).

8a.  corollary: request methods should NOT be used as part of the
cache key for returned entities.  The reason: multiple entries under
the same URI contribute to the "evil doppelganger" problem.  (Among
standard HTTP methods, only GET and HEAD could ever fetch the cached
results of other method requests).  Cacheability of returned results
is entirely controlled by metadata in headers.

Received on Wednesday, 13 September 1995 14:41:43 UTC