Subject: Using server-driven negotiation

From: Andrew Daviel <[email-masked]>
Date: Tue, 4 Dec 2007 13:34:59 -0800 (PST)

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

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 05 Dec 2007 12:43:52 +1300

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.

Regards

Adrien de Croy

Andrew Daviel wrote:
> 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.
>
> indication that different languages are available if the client were 
> to ask.
>
> Or, should we use a different extension header for the server to 
> indicate its willingness to accept position data and hence trigger a 
> dialogue,
> previously referred to geopriv, but I'd appreciate the HTTP expertise 
> of this group
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 4 Dec 2007 19:50:48 -0500

> in the next and subsequent requests, and cached responses could be

I think that's a reasonable action to take based on the information
the server is communicating.  It shouldn't be the only way though, if
only because a server may be interested in consuming geo info, but not
using it in determining the returned representation.

You should also be aware of the problems IE < 7 has with the Vary header.

> such as "Accept-Geo-Position: true"

Sure, though I'd avoid "Accept-*" since those are typically request
headers.  An HTML extension or two might be useful too: one for the
head, and one for forms perhaps.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

---

From: Andrew Daviel <[email-masked]>
Date: Tue, 4 Dec 2007 17:08:56 -0800 (PST)

> My 2c on the draft.

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

I'm not really suggesting that these usage cases would be cacheable, I 
just wanted to do it "right" so that incorrect cached responses would not 
be returned. We also specified a country or region code that is more 
likely to give cacheable pages than a numeric position, and Vary seems a 
better way than just setting Cache-Control: no-cache.

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

One of the authors has a module for mobile IE to take a GPS location and 
add it to each request, while I was playing with an HTTP proxy that does 
something similar. So the user isn't entering a position manually for 
each request, they are just browsing normally and the server is serving 
up location-dependant advertisements, or maps, or something.
I'm not sufficiently familiar with AJAX to see how this could be done 
without a user interaction.

>
> I'd also caution against using location as a means of selecting a language,

I didn't mean it like that; I mentioned language purely as an example of
current server-based negotiation.

> considered using an X- header?

That would work. As in X-xxxx: value, as opposed to registering a new 
formal header ?
I didn't see it in 2616.

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 05 Dec 2007 14:53:43 +1300

Andrew Daviel wrote:
>> 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
>
> just wanted to do it "right" so that incorrect cached responses would 
> not be returned. We also specified a country or region code that is 
> more likely to give cacheable pages than a numeric position, and Vary 
> seems a better way than just setting Cache-Control: no-cache.
OK.  I think the result of recent discussions on this list about 
intermediary interpretation of Vary headers means it shouldn't be a 
problem for properly designed proxy caches to be able to use an 
unrecognised header to compare against a subsequent request.  at the end 
of the day, you're only looking here about saving a round-trip to the 
server if the content is the same.

>> 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).
>
> One of the authors has a module for mobile IE to take a GPS location 
> and add it to each request, while I was playing with an HTTP proxy 
> that does something similar. So the user isn't entering a position 
> manually for each request, they are just browsing normally and the 
> server is serving up location-dependant advertisements, or maps, or 
> something.
If you've got a module that can get the information into the browser, 
that solves that issue, although presumably that case then only really 
considers the current user location (unless it has a selector to choose 
another location other than that provided by GPS).

I understand what you mean about the proxy now too - the proxy would be 
configured to include the header denoting the location of the network 
the proxy was serving for (to save having to get each client on that 
network to do so).

I guess the toss-up is whether to use something like this vs having to 
pay for a service like Maxmind GeoIP, where the server makes an 
assumption about the location of the user based on their IP.

> That would work. As in X-xxxx: value, as opposed to registering a new 

Hmmm I'd better have another look myself... hope I haven't put you wrong 
there.  I thought there were extension headers, but I read too many RFCs...

 From RFC2616 section 5.3

"Request-header field names can be extended reliably only in combination 
with a change in the protocol version. However, new or experimental 
header fields MAY be given the semantics of request- header fields if 
all parties in the communication recognize them to be request-header 
fields. Unrecognized header fields are treated as entity-header fields."

I'm not sure as to whether an entity header field needs to be 
accompanied by an entity or not.  Section 4.3 kinda implies that it 
should (except in the case of the HEAD command).

I think others on this list can provide you much better information on 
this than I can sorry, hope I haven't put you astray.

Regards

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 06 Dec 2007 16:07:15 +0100

On tis, 2007-12-04 at 13:34 -0800, Andrew Daviel wrote:
'
> indication that different languages are available if the client were to 

Yes. Vary lists the header the server looked for when determining the
response. Not only the headers the server found..

> generate a user dialogue if the server was not previously known.

Yes, if the response varies based on the position.

> in the next and subsequent requests, and cached responses could be 

Yes, that's fine.

> 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

---

From: "Subbu Allamaraju" <[email-masked]>
Date: Sat, 8 Dec 2007 12:16:11 -0800

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.

Regards,
Subbu

On Dec 6, 2007 7:07 AM, Henrik Nordstrom <[email-masked]> wrote:

> indicate

---

From: Robert Siemer <[email-masked]>
Date: Sat, 8 Dec 2007 21:26:19 +0100

> 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

---

From: Subbu Allamaraju <[email-masked]>
Date: Sat, 8 Dec 2007 12:45:28 -0800

> No Vary header means that the requested URI has just one variant, no

Great. Thanks.
Subbu

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 8 Dec 2007 21:39:10 +0000

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.

You said the server returns a generic reponse, and it does not vary
the response.

Well, does the server supply a different response when there is an
Accept-Geo-Position in the request?

If it does, that _is_ varying the response, and you've contradicted
yourself, and it should use the Vary header.

-- Jamie

---

From: Subbu Allamaraju <[email-masked]>
Date: Sat, 8 Dec 2007 13:47:14 -0800

> yourself, and it should use the Vary header.

I see. The "generic" itself is a varied form.

Subbu

---

From: Andrew Daviel <[email-masked]>
Date: Tue, 11 Dec 2007 22:05:15 -0800 (PST)

>> No Vary header means that the requested URI has just one variant, no

Thanks for the opinions.

That matches what Apache does - sends  Vary: 
accept-language,accept-encoding even 
if the client does not send Accept-Language etc.