Re: Changes to Content Negotiation, Entity Tags, and If-*

>According to Draft 03:
>  In a request message on a generic resource, the selecting request
>  headers are those request headers whose contents were used by the origin
>  server to select the entity best matching the request. The Vary header
>  field specifies the selecting request headers and any other selection
>  parameters that were used by the origin server.

>   GET /fred HTTP/1.1       French html             French html
>   Host:    [no Vary header]        Vary: Accept,
>                                                          Accept-Language

You're example is absolutely correct.  I think this is a case of cofusing
wording in the draft.  I don't/can't beleive that is how Koen meant for it
to be interpreted.   "Those request headers" do not necessarily have to be a
subset of the request headers that were present in the GET /fred request,
but rather "those request headers" could be interpreted to be a subset of
the request headers listed in the HTTP spec.  The wording is just bad
because it doesn't adequately convey the role of non-existant headers on ayn
particualr request.

You don't really think that's what Koen and the rest of the conneg group
meant do you?

>Is that clear enough yet, or do I have to describe every aspect of
>caching and content negotiation in order to convince people once again
>that the principal designer of the HTTP/1.1 protocol actually knows
>how it is supposed to work and isn't just spouting off because he likes
>to hear himself type?
>out enough flaws in draft 03 to demonstrate that it is utterly wrong
>in its depiction of content negotiation, and therefore cannot be allowed
>to remain "as consensus" within the HTTP/1.1 spec.  End of discussion
>as far as I am concerned.

And this attitude is supopsed to be condusive to consensus?

>    Alternates: whatever
>is equivalent to
>    Vary: {accept-headers}
>because it would cause all applications that only understand Vary to
>think that the response varies on ALL of the Accept* headers and not
>on just the one or two that most such responses will vary upon.
>Furthermore, that isn't sufficient, since we haven't even decided
>yet whether the scope of Alternates should be limited to Accept*,
>or also include things like regular expressions on the User Agent
>field, or feature sets based on agent profiles, or ANYTHING that
>hasn't been written in stone yet.

So we'll clear up any incompatibilities between the two and the handling of
nonsensical combinations in the Alternates: draft?  Will we later say
Alternates: overrides Vary:?  (Didn't you just say in an earlier message
that we can't design the protocol to have one header override an another?)
I'm not playing devil's advocate here, I just want to be assured that our
design of Vary now is not going to screw up my concept of transparent
negotiation in the future.

Daniel DuBois, Software Animal          

Received on Wednesday, 29 May 1996 09:23:26 UTC