W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

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

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 19 Jul 2011 10:08:03 +1000
Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis Group <ietf-http-wg@w3.org>
Message-Id: <6116BAB7-ED31-4FF7-A6AD-F7564834E603@mnot.net>
To: Adrien de Croy <adrien@qbik.com>
Vary: *


On 19/07/2011, at 10:03 AM, Adrien de Croy wrote:

> 
> 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/
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 19 July 2011 00:08:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:45 GMT