Re: Comments on draft-ietf-http-negotiation-00.txt

On Thu, 20 Feb 1997, Koen Holtman wrote:
> Klaus Weide:
> >--- begin excerpt ---
> >|10.5 Extracting a normal response from a choice response
> >   [...]
> >|  For security reasons (see section 14.2), an extracted normal
> >   response may only be cached if the negotiable resource and the
> >   variant resource are neighbors.  If they are not neighbors, the
> >   proxy should reject the choice response as a probable spoofing
> >   attempt and pass on a 502 (bad gateway) error response instead.
> >--- end excerpt ---
>[...] 
> >(b) I don't think a proxy should do this (behaviour of last sentence,
> >    i.e. refuse to forward such a choice response to the client.  This
> >    is of course different from the "no extracting" rule).
> >    (i) The user agent has the same information available as the proxy
> >        from the response headers - if proxy forwards the response -
> >        to decide whether this is a probable spoofing attempt, if it
> >        is concerned about that.  This is already covered in the last
> >        paragraph of 11.1 for a t.c.n.-supporting client.  (And a user
> >        agent which does not support t.c.n would not get a cached choice
> >        response anyway, because it hasn't sent "Negotiate:", right? [*])
> 
> Right, except that the server may also choose to send choice responses to
> non-negotiating agents.  If it does, the non-negotiatiing agent can get a
> choice response.

Ok, I see that. (and it gets more complicated if there is a mixture of
t.c.n.-aware and HTTP/1.1 and HTTP/1.0 proxies on the path...)

> >        So there is no need for a proxy to play policeman for exchanges
> >        in which it may not be involved beyond the usual caching and
> >        forwarding.
> 
> The general philosophy of the 1.1 caching mechanism is that caches do need
> to play policeman.  At least that is my interpretation of Jeff's design, the
> Age header requirements are a good example of this philosophy.  

But is there a precedent for requiring a proxy *not* to forward a response
to a client at all, even when it is (a) a valid HTTP message, and (b)
directly from the origin server?  Note that your formulation would require
this even of a non-caching proxy.

> This point
> is debatable though, and I would not mind to leave out this `should'.
> 
> If somebody seconds the idea that the proxy should not police this case,
> I'll cut the stuff.
> 
> >    (ii) It seems to be a property of the 1.0 rvsa that non-neighboring
> >        variants are never returned in a choice response.
> 
> If it seems that way, I was not clear enough in the main draft.  The main
> draft is supposed to _always_ require this, no matter what the rvsa.  It is
> a general security feature after all.  I'll add some more text to make this
> clearer.

Maybe it was wishful thinking that I thought a choice response like the
following would not be "forbidden" by the basic t.c.n.:

[ for a request of GET http://x.org/paper, as in your examples ]

     HTTP/1.1 200 OK
     Date: Tue, 11 Jun 1996 20:05:31 GMT
     Content-Type: text/html
     Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
     Content-Length: 5327
     Cache-control: max-age=604800
     Content-Location: en/paper.html
     Alternates: {"en/paper.html" 0.9 {type text/html} {language en}},
                 {"fr/paper.html" 0.7 {type text/html} {language fr}},
                 {"en/paper.ps"   1.0 {type application/postscript}
                     {language en}}
     Etag: "gonkyyyy;1234"
     Vary: negotiate, accept, accept-language
     Expires: Thu, 01 Jan 1980 00:00:00 GMT

     <title>A paper about ....

While the -negotiation- draft has some special rules and `should's
regarding variant resources as neighbours of negotiable resource,
it doesn't state that responses are always invalid if this is not the
case.  (It seems at least acceptable for list responses).

B.t.w. do the rules of RFC 2068 3.2.3 for comparison of URLs apply when
determining whether two resources are neighbors?  (Should probably
be clarified.)


> >- There is an ambiguity in the terminology (maybe throughout all three 
> >  drafts), in that "Accept header(s)" mostly refers to all 4 of "Accept:", 
> >  "Accept-Charset:", "Accept-Language:", and "Accept-Features:",
> >  but in some cases just to "Accept:"
> >  (draft-ietf-http-rvsa-v10-00.txt 3.3 qt, 3.4 1., 4.2.1 2nd sentence,
> >   4.2.2 are examples)
> 
> Yes, this is mainly for stylistic reasons.  I could use `Accept* headers' or
> `Accept-* headers' to denote the set, but I think it is ugly.  If you think
> that the ambiguity can be confusing, I'll make it uglier and less ambiguous.

Since in most cases `Accept header' refers to the general meaning, you
could use `"Accept" header' for the few other cases.

> A related issue: I also don't capitalise MUST, MAY, and SHOULD, again because
> it is ugly.  I could be persuaded to change this if enough people want it.

That ould help to decide whether an application is "TCN conformant" (if 
you want to define such a thing..).

  Klaus

Received on Thursday, 20 February 1997 15:55:15 UTC