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:25:05 +1000
Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis Group <ietf-http-wg@w3.org>
Message-Id: <0FAF92F5-30ED-4630-80DE-B81FAB699767@mnot.net>
To: Adrien de Croy <adrien@qbik.com>
It's been discussed before, and there might be some future work on a more fine-grained replacement for Vary. But not as a work item under this charter :)

Cheers,


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

> 
> well I guess that means that the Vary header can only refer to request headers or "*", and therefore cannot refer to all the attributes that were used to select the representation.
> 
> I realise this is probably a vanishingly small benefit, but I wonder if there is any use for a concept of well-known tokens for such things, or concept of virtual request headers, which amount to the same thing.  E.g any request can be deemed to contain the headers
> 
> ClientIp: <ipaddress>
> TransportProtocol: <transport protocol>
> etc
> 
> then it can be referred to by Vary, cache-control etc, and intermediate caches can then do something useful with content which varies on it, rather than the server just blanket forcing revalidation with Vary: *
> 
> ClientIp is obviously difficult when it comes to proxies, as the O-S won't see the client IP unless it is forwarded in another header (such as X-F-F).  So actually maybe giving the example of the client IP is misleading in the prose.
> 
> Apologies if this is pedantism taken too far.  There could be some interesting possibilities with considering this is all.
> 
> Adrien
> 
> 
> On 19/07/2011 12:08 p.m., Mark Nottingham wrote:
>> 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/
>> 
>> 
>> 
> 
> -- 
> 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:25:36 GMT

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