- From: Andrew Daviel <advax@triumf.ca>
- Date: Tue, 4 Dec 2007 13:34:59 -0800 (PST)
- To: ietf-http-wg@w3.org
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 ask. 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. http://geotags.com/geo/draft-daviel-http-geo-header-05.txt (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