- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 19 Jul 2011 12:18:27 +1200
- To: Mark Nottingham <mnot@mnot.net>
- CC: Julian Reschke <julian.reschke@gmx.de>, httpbis Group <ietf-http-wg@w3.org>
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/
Received on Tuesday, 19 July 2011 00:19:05 UTC