Re: Using server-driven negotiation

On Sat, Dec 08, 2007 at 12:16:11PM -0800, Subbu Allamaraju wrote:
> I have a question. Is the server required to supply a Vary header when it
> did not actually vary the current response?
> In the example below, in the absence of a header line Accept-Geo-Position in
> the request, the server may be returning a generic response. In this case, I
> would assume that the server will not set the Vary header. I am unable to
> find any reference to this in 2616. Hence the question.

Yes, it needs to send Vary: accept-geo-position to signal to any cache 
on the way that the response _does_ vary based on that header.

The Vary header is not a signal that the server chose a not-so-common 
response. The "generic response" as you call it, was based on that 
header, that is the point of Vary.

No Vary header means that the requested URI has just one variant, no 
matter what.


Regards,
		Robert



> On Dec 6, 2007 7:07 AM, Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> 
> > On tis, 2007-12-04 at 13:34 -0800, Andrew Daviel wrote:
> > '
> > > As I read the RFC, a server should send a Vary header to indicate that
> > > the response should only be cached if the listed header values match.
> > > When I look at the Apache server, I see that it sends "Vary: lang"
> > > even for requests without "Accept: lang", so maybe it's also an
> > > indication that different languages are available if the client were to
> > > ask.
> >
> > Yes. Vary lists the header the server looked for when determining the
> > response. Not only the headers the server found..
> >
> > > What I was wondering is, would it be acceptable for a server to
> > > send "Vary: geo-position" to an initial request, which would then
> > > generate a user dialogue if the server was not previously known.
> >
> > Yes, if the response varies based on the position.
> >
> > > The client would then send "Geo-Postion: lat;long" (or not)
> > > in the next and subsequent requests, and cached responses could be
> > > re-used on match.
> >
> > Yes, that's fine.
> >
> > > Or, should we use a different extension header for the server to
> > indicate
> > > its willingness to accept position data and hence trigger a dialogue,
> > > such as "Accept-Geo-Position: true"
> >
> > The two doesn't exclude each other.
> >
> > With "Vary: Geo-Position" the server says "I am interested in your
> > position as the response varies depending on where you are.
> >
> > With a new "I want Geo-Position" header without using Vary the server
> > says "I want to know your position for tracking reasons, but it doesn't
> > affect the response I send to you".
> >
> > Accept-Geo-Position is probably not a name for the header unless you
> > want to define a syntax for specifying what kinds of geo-position the
> > server accepts.. should be someting not starting with Accept- I think.
> >
> > I suggest you start with Vary, and then look into additional in-band or
> > out-of-band negotiation of the feature if found needed.
> >
> > Note: There was a releated proposal some timeago how to negotiate
> > extensions, with the aim of controlling transmission of user personal
> > information / profile.
> >
> > Regards
> > Henrik
> >

Received on Saturday, 8 December 2007 20:26:04 UTC