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

Well, I cleverly convinced the SmartList mail manager to remove
me from the list without me knowing it, so I missed 10 messages
and will have to get them from Andy later (558-567, if you are wondering).

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
Second client:

   GET /fred HTTP/1.1       English html            English html
   Host: www.ics.uci.edu    Vary: Accept-Language   Vary: Accept,
   Accept-Language: en                                    Accept-Language

Third client:

   GET /fred HTTP/1.1       French PDF              French PDF
   Host: www.ics.uci.edu    Vary: Accept            Vary: Accept,
   Accept: application/pdf                                Accept-Language

Okay, now what happens when the first client was a shared cache
which is also used by the second agent?  According to draft 03,
the cache will give the second agent the cached French html entity,
thus defeating the only reason we have Vary in the protocol.

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?

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.  We cannot just say that 

    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.

Alternates will never be a complete replacement for Vary, because
there is no way to express

    Vary: cookie

as an equivalent within Alternates.  Yes, that is a relevant example
for sites that use the cookie for holding simple preference flags.

The obvious reason why {extension-vary-token} is not needed is because
the Alternates header field is one example of an extension of Vary.
Would you like us to require that the functionality of Alternates
be restricted to a {token} in Vary?  Does a lack of that {token} in
Vary mean that we won't be able to add Alternates?  Well then, why do
we need it?

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.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 29 May 1996 00:30:42 UTC