Re: ISSUE VARY: Proposed wording

Henrik Frystyk Nielsen:
>
>
>Description of Problem
>
>	http://www.w3.org/Protocols/HTTP/Issues/#VARY
>

[....]

Some nitpicks:


>Proposed changes to Section 13.6:

>4th Paragraph:
>
><<<<<
>The Vary header field may also inform the cache that the representation was
>selected using criteria not limited to the request-headers; in this case, a
>cache MUST NOT use the response in a reply to a subsequent request unless
>the cache relays the new request to the origin server in a conditional
>request and the server responds with 304 (Not Modified), including an
>entity tag or Content-Location that indicates which entity should be used.
>=====
>The Vary header field MUST also inform the cache that the representation
                                                  ^^^^if

>was selected using criteria not limited to the request-headers; in this
>case, a cache MUST NOT use the response in a reply to a subsequent request
>unless the cache relays the new request to the origin server in a
>conditional request and the server responds with 304 (Not Modified),
>including an entity tag or Content-Location that indicates which entity
>should be used.
>>>>>>


>Section 14.43

>2nd Paragraph:
>
><<<<<
>An HTTP/1.1 server MUST include an appropriate Vary header field with any
>cachable response that is subject to server-driven negotiation. Doing so
>allows a cache to properly interpret future requests on that resource and
>informs the user agent about the presence of negotiation on that resource.
>A server SHOULD include an appropriate Vary header field with a
>non-cachable response that is subject to server-driven negotiation, since
>this might provide the user agent with useful information about the
>dimensions over which the response might vary.
>=====
>An HTTP/1.1 server MUST include a Vary header field with any cachable
                                 ^^^
 why did you leave out `an appropriate'?  I think that leaving this
 out makes the text worse.  `an appropriate' signals that is the
 responsibility of server to ensure that the client does the right
 thing based on the vary header field contents.

>response that is subject to server-driven negotiation. Doing so allows a
>cache to properly interpret future requests on that resource and informs
>the user agent about the presence of negotiation on that resource. A server
>SHOULD include a Vary header field with a non-cachable response that is
>subject to server-driven negotiation, since this might provide the user
>agent with useful information about the dimensions over which the response
>vary at the time of the response.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Again, I liked the old text better.  The addition of `at the time of the
 response' only begs questions which need not be answered.


>Henrik

Koen.