Re: list of pending proposals

Balint Nagy Endre writes:
 > Shel Kaphan writes:
 > > 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?

The point of invalidating rather than believing the Location URI and
using it as a cache key is that invalidating with a forgery is only a
misdemeanor whereas caching with a forgery is a felony.  I claim
that with invalidation it isn't worth worrying about forgeries. I
gave up on the cache-key idea because the complexity of managing the
security controls necessary to make it safe seemed to far outweigh the
slight cache performance benefit.

 > > 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?

I'd prefer if they MUST forward requests, with certain constraints
(e.g. when no protocol translation is required), but that might not be
backward compatible enough.

 > > 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?
Yes. :).
 (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.

Seems too complicated to me, for unstated benefit.  A variant that I'd
go for would be the most restrictive directive wins, though nobody
(not even Roy) has yet said why the existence both response headers is
a good idea in the first place.
	...

 > > 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.
As above, I decided the sanity checks are more trouble than the
benefits that could be gained.

 > > 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.
What sanity checks do you mean? This proposal is actually a
proposal in the direction of making things more CONSERVATIVE.
An even more conservative approach would be that only GET can cache its
results and use those results later, but I don't like that.

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

Shel

Received on Thursday, 14 September 1995 15:44:07 UTC