- From: Klaus Weide <kweide@tezcat.com>
- Date: Tue, 18 Feb 1997 19:16:50 -0600 (CST)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Tue, 18 Feb 1997, Koen Holtman wrote:
> >In message <Pine.SUN.3.95.970217175449.6072C-100000@xochi.tezcat.com>,
> >Klaus Weide writes:
> >>10.2, in description of the algorithm:
> >>--- begin excerpt ---
> >> 3. Check for an origin server configuration error. If the HTTP
> >> response message generated in step 2 contains an Alternates
> >> header, a Content-Location header, or has the 300 status code,
> >> ^^^^^^^^^^^^^^^^
> >> then the best variant resource is not a proper end point in
> >> the negotiation process, and a 506 (Variant Also Negotiates)
> >> error response message should be generated instead of going to
> >> step 4.
> >>--- end excerpt ---
> >>
> >>This seems slightly too restrictive. Suggestion: change to "[...],
> >>a non-matching Content-Location header, [...]", and add:
> [...]
>
> What about this: the check for a content-location header is removed, and in
> step 4a which adds a content-location header, I add a note that the added
> content location header must overwrite any content-location header already
> present.
Checking for an inconsistent Content-Location still may make sense.
I also had this in mind (from RFC 2068, 13.5.2):
--- begin excerpt ---
A cache or non-caching proxy MUST NOT modify any of the following
fields in a request or response, nor may it add any of these fields
if not already present:
o Content-Location
o ETag
o Expires
o Last-Modified
--- end excerpt ---
But 10.2 4.a and 4.f (adding Content-Location and modifying Etag) are
in violation of that prohibition anyway, if the algorithm is running
on a proxy instead of the origin server. [Some ideas come to mind how
you could talk yourself out of that: (a) State upfront that this is a
new protocol which sopersedes/obsoletes certain HTTP/1.1 rules;
(b) insist that the newly constructed response is not really the same
response at all, but a totally new thing only based on the variant
[[Hmm, so the proxy is not acting as a HTTP "proxy" then, for this message,
but rather as a "gateway"?]] ]
Anyway, the intention of the above quoted passage from HTTP seems to
be "Never second-guess the origin server, only it can know these things
with autority", so silently dropping (and then replacing) an unexpected
Content-Location header with a bogus value may be wrong.
>[...]
> >> Use of this header
> >>should not be discouraged by the negotiation draft
>
> Well, the algorithm always add a content-location header, so this is not
> really diminishing use.
Right, but I was thinking about the communication between a proxy
running this algorithm and the origin server, and proxies in between which
might be content-location-aware but not t.c.n.-aware.
> I added the check to make it easier for service
> authors to find out about configuration inconsistencies in the server. But I
> guess you are right that the current wording is too restrictive.
How about this:
(a) In 10..2 3. strike C-L from the explicit list of headers to be checked,
(b) append something like the following:
"Other checks MAY also be performed, possibly based on local
configuration, to ensure that the response message contains a proper
variant of the negotiable resource and that the choice response
generated in the next step is valid according to the underlying
protocol (e.g. HTTP/1.1). If these checks fail, an appropriate error
response message SHOULD be generated instead of going to step 4."
(c) change formulation in 4.a to make sure only one C-L header will
be present in end result.
That moves the C-L question into a "valid according to HTTP/1.1" catch-all
and also covers some other things.
-----
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.
(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? [*])
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.
(ii) It seems to be a property of the 1.0 rvsa that non-neighboring
variants are never returned in a choice response. But that
is a property of that specific rvsa, other rvsa versions may
allow non-neighbor choice responses. If such a rsva has been
negotiated between a user agent and (e.g.) origin server, an
intermediate proxy should not interfere (it may not understand
this rsva version at all).
(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)
- You use "header" where RFC 2068 uses "header field". (not necessary
a problem, just an observation)
- In draft-ietf-http-feature-reg-00.txt:
Make sure "*" and things starting with '!' cannot be registered.
Klaus
Received on Tuesday, 18 February 1997 17:22:28 UTC