Re: list of pending proposals

Shel Kaphan writes:
> 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
As I see, real decisions are made by Roy. (e.g. when Roy thinks, that 
consensus exists, incorporates the proposal into current draft.)
Need we more formal decisions? (If Roy has enough time to write down
appropriate proposals, I think not.)
> 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).
which sanity checks can/should be done before beliving that URI in the
Location isn't a forgery?
> 2. Proxies should be allowed to forward requests for methods that they
> do not understand, instead of being required to return 501.
conditionally or uncondititonally?
> 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.
is this enough? (I mean my speculations on 'server-control',
but I am still unsure, which is the right approach: Shel's alternative
or my.)
> 4. Cache-control: max-age=nnn  cannot appear in same response as 
> Expires: <date>.  If both appear, the Cache-control wins.
an alternative: cache-control max-age=n has effect only after <date>
if Expires: <date> present.
> 5. Cache-control: no-cache cannot appear in same response as
> Expires: <date>.  If both appear, the Cache-control wins.
Ok, cache-control: no-cache is the most restrictive.
> 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.
I like the second (no effect on history from servers, history is strictly
local)
> 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.
yes, it makes sense. (not doing it makes non-sense)
> 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).
this depends on sanity checks required/recommended, I think.
> 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.
Sanity checks again.

And a question:
shall all WG members list their own pending proposals, not acked/nacked
by Roy and not cancelled by author?

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunt.hu>

Received on Wednesday, 13 September 1995 15:49:36 UTC