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: www.ics.uci.edu    [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          
                                     dan@spyglass.com
                                     http://www.spyglass.com/~ddubois/

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