Re: Using server-driven negotiation

Andrew Daviel wrote:
> On Wed, 5 Dec 2007, Adrien de Croy wrote:
>
>>
>> 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.
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.

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

> If you really want to convey this information in a header, have you 
> 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.

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

>
>
>

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

Received on Wednesday, 5 December 2007 01:53:02 UTC