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

Roy T. Fielding:
>
[...]
>As I recall (before I unfortunately deleted it), Dan cc'd me on a
>message in which he asked for a clear explanation of why the draft 03
>definition of Vary was completely and absurdly wrong (not in those words).
>Here it is.
>
>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.
>
>Okay, let's try it in practice.  We have a resource called /fred which
>provides negotiated 200 responses on GET requests in French html, English
>html, and French PDF in that order of quality.
>
>First client:               Draft 03 response       Correct Response
>
>   GET /fred HTTP/1.1       French html             French html
>   Host: www.ics.uci.edu    [no Vary header]        Vary: Accept,
>                                                          Accept-Language
                             ^^^^^^^^^^^^^^^^

This is an incorrect description of what the 03 response must be.
Under the draft-03 text, the correct response is also `Vary: Accept,
Accept-Language', just like you would expect.  These are the two
headers that the origin server used to select the response.  I don't
see any way to interpret the 03 text in such a way that no vary header
may be sent.

Below, I include a message in which I discussed the situations in
which contents of the 03 vary header and Roy's vary header can indeed
differ.

[....]
>Vary and Alternates (what I originally defined within the URI header)
>are independent of one another because that is the only design that
>will work in a world where some applications will understand Vary but
>not have a clue about Alternates.

I agree to them being orthogonal.  Were exactly does the 03 text
incorrectly state that Vary and Alternates are not orthogonal?

[...]
>Even if it was the consensus of the entire WG, I have already pointed
>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.

I find that your analysis of the utter wrongness of the 03 content
negotiation text is faulty.  In my eyes, you are using a faulty
analysis to push through last-minute trivial twiddles to syntax and
semantics, some of which even damage 1.1.

I don't see much value in continuing the discussion about who is right
and wrong on this.  I'll just read Jim's new draft and will report on
the things that need to be changed.

> ...Roy T. Fielding

Koen.


--snip---

>From my mail archive:

Larry Masinter:
>

[Note: I didn't see the original message.  Is there something wrong
with my mail system?]

>
>> if one entry has
>>       Vary: Accept-Language, Accept-Charset
>> and the other has
>>       Vary: Accept-encoding
>> it's possible that a request could match both of them.

Yes, this is possible, and if a request matches both, the cache is
allowed to send either entry to its client.  Of course, this is not
very meaningful behavior, so the resource author has to avoid sending
one entity instance with
    Vary: Accept-Language, Accept-Charset
and one with
    Vary: Accept-encoding 
.  If such Vary non-overlapping Vary headers
are sent, this will likely indicate a programming error made by the
resource author.

>I think this is an error condition, and that a cache shouldn't keep
>two entries that differ in the set of request headers that the
>resource should vary on.

Sending different Vary headers on different variants is not
specifically forbidden by the protocol.  A meaningful application
would be if you have three variants:

1) English, text/html variant
    includes Vary: Accept-Language, Accept

2) English, application/postscript variant
    includes Vary: Accept-Language, Accept

3) French, text/html variant
    includes Vary: Accept-Language

>The 'Vary' header describes not just the particular entity instance
>but the entire resource-at-that-time.

No, the Vary header does describe a property of the particular entity
instance, the property being the request headers used for selecting
that particular instance.  The reason for this is that the caching
model talks only about particular instances being cached and becoming
stale, not about entire resources doing so.  Thus, I defined the
caching rules associated with the vary header by talking about
lifetimes of entity instances.  A Vary header applying to the whole
resource would not have inferior semantics, but would be more
difficult to define.

Koen.

Received on Wednesday, 29 May 1996 01:42:48 UTC