W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

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

From: Koen Holtman <koen@win.tue.nl>
Date: Thu, 20 Feb 1997 22:26:45 +0100 (MET)
Message-Id: <199702202126.WAA04728@wsooti08.win.tue.nl>
To: Klaus Weide <kweide@tezcat.com>
Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2503
Klaus Weide:
>Some other remarks:
>--- 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 ---
>(a) The *last* sentence doesn't seem to belong in this section -
>    it is not about extracting or what to do with an extracted "normal"
>    response, but about what to do when a certain kind of choice response
>    is received.

OK, I'll see If I can move it to a better place.

>(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.

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

>(c) Not chaching such a choice response (in addition to not caching the
>    "extracted normal response") is a different matter, no problem with that.
>[*] Actually I don't know whether this is true, or under which conditions
>    it is..
>- 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.

>- You use "header" where RFC 2068 uses "header field".  (not necessary
>  a problem, just an observation)

Yes.  Style again.  Everybody says `header' on the list, so that is what I

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.

>- In draft-ietf-http-feature-reg-00.txt:
>  Make sure "*" and things starting with '!' cannot be registered.

We will.

>   Klaus

Received on Thursday, 20 February 1997 13:33:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC