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
clearer.
>(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
use.
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
Koen.