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

Re: list of pending proposals

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Fri, 15 Sep 1995 08:38:36 +0200 (MET DST)
To: Shel Kaphan <sjk@amazon.com>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <48.bne@bne.ind.eunet.hu>
Shel Kaphan writes:
> 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.
Having url http://server[:port]/path/foo.html.xyz to be invalidated/superseded
by a script, I can setup cern-httpd to have the script path name looking:
http://server[:port]/path/foo.bin.blah. (e.g. making the situation similar to
my example /Welcome URL.) In this case, we can define the sanity check as:
URI given in a Location header field value and the request-URL
must have common prefix
http://server[:port]/path/foo, (stripping off everithing starting from
first dot after the last slash in request-URI and Location-URI must result
the same string.) The problem with this definition is:
depends on special interpretation of slash-es and dots in an URL.
(All implementations I know interpret an URL this way, but it is only a
common practice, not a requirement. The relative URL RFC requires this
interpretation of slash character, but special semantics for dot character
is a new requirement.)
Adding this restriction to location-URI excludes the forgery problem,
but may have unvanted side effects.

>  > > 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.
I'm still unsure.
We have 3 alternates:
unconditional 501 (Roy)
dont check on method at all (Shel)
server-control (bne)
Rationale behind server-control:
If some decisions can and should be made on extension headers, only proxies
understanding those extension headers are allowed to forward the request.
(this may be not eligible in some cases, may leave open backdoors built
into extension methods. I'm sure, we shall discuss security aspect first.)
>  > > 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.
We can clarify this, see my proposal in message <42.bne@bne.ind.eunet.hu>.
> 	...
> 
>  > > 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.
If the first dot after the last slash in an URL is the possible starting
point of variance, we have a simple and eligible check.
>  > > 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.
If we have enough good sanity check, we don't need this restriction.
Not having sanity checks, this restriction *may* be a MUST.
> 	...
Andrew. (Endre Balint Nagy) <bne@bne.ind.eunt.hu>
Received on Thursday, 14 September 1995 23:52:44 EDT

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