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

Using server-driven negotiation

From: Andrew Daviel <advax@triumf.ca>
Date: Tue, 4 Dec 2007 13:34:59 -0800 (PST)
To: ietf-http-wg@w3.org
Message-ID: <Pine.LNX.4.64.0712031453530.18059@andrew.triumf.ca>

We are looking at an application using HTTP extension headers for
server-driven negotiation, as defined in rfc2616.

Instead of "Accept-Lang: FR" (send the page in French if you can), we 
want to use something like "Geo-Position: 49;-123" (send a page tailored 
to the Vancouver area).

Privacy issues require us to maintain a list of sites or URLs to which we 
will send location data and how fuzzy it should be (on the basis that 
there's a good chance the position we are interested in is where we are 
right now). The user interface to this filter might be a popup GUI e.g. 
as used in Firefox for cookies, which means that the server needs some 
way to indicate that it's willing to accept location data in order to 
trigger the popup.

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 

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.
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.

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 idea is to have something in-band that can be handled by
CGI/PHP on the server, and by a proxy or browser add-on in the client, 
rather than requiring a whole new application.

(not yet at IETF; version 4 has expired)
previously referred to geopriv, but I'd appreciate the HTTP expertise of 
this group

Andrew Daviel, TRIUMF, Canada
Received on Tuesday, 4 December 2007 21:35:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC