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

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

Received on Monday, 18 July 2011 17:32:57 UTC