Re: #285: Strength of requirements on Accept re: 406

Hi

just an observation.

An example in the prose below refers to a server wanting to vary the 
response based on say the client IP.

How would it specify that in a Vary header?

Since that's not actually a request header, I don't see how the server 
can emit a vary header which refers to it.

We would need some standardised tokens to represent such things, 
otherwise caching intermediaries cannot store and use the correct metadata.

Regards

Adrien


On 19/07/2011 5:32 a.m., Julian Reschke wrote:
> On 2011-07-17 04:19, Mark Nottingham wrote:
>> Proposal:
>> ...
>
> Works for me; proposed patch in 
> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/285/285.diff>.
>
> I wasn't entirely sure where to put the new text in 5.1; right now the 
> whole subsection reads like this...:
>
> 5.1.  Server-driven Negotiation
>
>    If the selection of the best representation for a response is made by
>    an algorithm located at the server, it is called server-driven
>    negotiation.  Selection is based on the available representations of
>    the response (the dimensions over which it can vary; e.g., language,
>    content-coding, etc.) and the contents of particular header fields in
>    the request message or on other information pertaining to the request
>    (such as the network address of the client).
>
>    Server-driven negotiation is advantageous when the algorithm for
>    selecting from among the available representations is difficult to
>    describe to the user agent, or when the server desires to send its
>    "best guess" to the client along with the first response (hoping to
>    avoid the round-trip delay of a subsequent request if the "best
>    guess" is good enough for the user).  In order to improve the
>    server's guess, the user agent MAY include request header fields
>    (Accept, Accept-Language, Accept-Encoding, etc.) which describe its
>    preferences for such a response.
>
>    Server-driven negotiation has disadvantages:
>
>    1.  It is impossible for the server to accurately determine what
>        might be "best" for any given user, since that would require
>        complete knowledge of both the capabilities of the user agent and
>        the intended use for the response (e.g., does the user want to
>        view it on screen or print it on paper?).
>
>    2.  Having the user agent describe its capabilities in every request
>        can be both very inefficient (given that only a small percentage
>        of responses have multiple representations) and a potential
>        violation of the user's privacy.
>
>    3.  It complicates the implementation of an origin server and the
>        algorithms for generating responses to a request.
>
>    4.  It might limit a public cache's ability to use the same response
>        for multiple user's requests.
>
>    Server-driven negotiation allows the user agent to specify its
>    preferences, but it cannot expect responses to always honour them.
>    For example, the origin server might not implement server-driven
>    negotiation, or it might decide that sending a response that doesn't
>    conform to them is better than sending a 406 (Not Acceptable)
>    response.
>
>    Many of the mechanisms for expressing preferences use quality values
>    to declare relative preference.  See Section 6.4 of [Part1] for more
>    information.
>
>    HTTP/1.1 includes the following header fields for enabling server-
>    driven negotiation through description of user agent capabilities and
>    user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2),
>    Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and
>    User-Agent (Section 9.9 of [Part2]).  However, an origin server is
>    not limited to these dimensions and MAY vary the response based on
>    any aspect of the request, including aspects of the connection (e.g.,
>    IP address) or information within extension header fields not defined
>    by this specification.
>
>       Note: In practice, User-Agent based negotiation is fragile,
>       because new clients might not be recognized.
>
>    The Vary header field (Section 3.5 of [Part6]) can be used to express
>    the parameters the server uses to select a representation that is
>    subject to server-driven negotiation.
>
>
> ...feedback appreciated,
>
> Julian
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 beta out now - http://www.wingate.com/getlatest/

Received on Tuesday, 19 July 2011 00:04:32 UTC