W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: Using server-driven negotiation

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 06 Dec 2007 16:07:15 +0100
To: Andrew Daviel <advax@triumf.ca>
Cc: ietf-http-wg@w3.org
Message-Id: <1196953635.4331.57.camel@henriknordstrom.net>
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 Thursday, 6 December 2007 15:07:47 GMT

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