- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Jul 2011 10:08:03 +1000
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis Group <ietf-http-wg@w3.org>
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 UTC