Re: Using server-driven negotiation

My 2c on the draft.

The use-cases discussed in section 3.1.1 of the draft are proposing an 
additional HTTP header to convey what would normally be considered to be 
form data (i.e. provided by POST or as part of a query string in a GET 
request).  In that respect, I don't consider those use cases compelling.

There is also considerable discussion on cache control implications and 
the Vary tag.  I'm struggling to see where something that varies by 
geographic location would be otherwise invariant (i.e. not vary on time, 
or other factors which are currently in the control of the server).  For 
instance the weather-map case, you are up against someone's ability to 
travel to a new location quicker than say satellite weather maps change.

There are technologies already that can use a browser and CGI to 
transfer the requisite information about location without using HTTP 
headers.  You can use Ajax to asynchronously POST location information 
to a script (i.e. to track moving hosts).  Also, wherever there is 
user-input required to define location, this could just as easily be in 
a form to post rather than in a custom configuration dialog in a browser 
(that would then require browser vendor support).

I'd also caution against using location as a means of selecting a 
language, since the Accept-Language header already deals with that 
explicitly and deterministically, whereas location to language mapping 
is an assumption which will occasionally be wrong, e.g. just because I 
may holiday in the Greek islands doesn't mean I suddenly want all my web 
surfing to be in Greek.

You could argue that why do we treat language differently then, and I'd 
have to agree with you, but language is something that is extremely 
commonly differentiated, whereas there may not be that many applications 
that wish to vary on geographic location and which cannot achieve good 
cache efficiency with the existing cache mechanisms.

If you really want to convey this information in a header, have you 
considered using an X- header?  Also how do you plan to get the location 
information into the browser without it being a custom browser?  If it 
needs to be entered by a user, most users would prefer to click on a map 
location than enter lat/long coordinates.  That map would be on a site, 
and result in a POST request.


Adrien de Croy

Andrew Daviel wrote:
> 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.
> (not yet at IETF; version 4 has expired)
> previously referred to geopriv, but I'd appreciate the HTTP expertise 
> of this group

Adrien de Croy - WinGate Proxy Server -

Received on Tuesday, 4 December 2007 23:43:13 UTC