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