RE: Geolocation header

I was thinking off the top of my head, the removal of JavaScript presents some opportunity for User Agents to make use of a feature that they’ve not had yet.

I guess it boils down to whether the geolocation header field is restricted to being request only, or if it could appear on responses. This could support cases such as a long-polling client talking to a moving endpoint (IoT), or just sensors that work in more of a push mode of operation (aka unidirectional flows).

Lucas

From: Luis Barguñó Jané [mailto:luisbargu@gmail.com]
Sent: 03 August 2017 16:20
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: ietf-http-wg@w3.org
Subject: Re: Geolocation header


On Wed, Aug 2, 2017 at 10:45 PM, Lucas Pardue <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> wrote:
Interesting.

How symmetrical is this proposal? I.e. Is there a use case where a user agent requests a geolocation from a server?

I can't think of any, but if you have something in mind, please let me know.


Regards
Lucas
________________________________
From: Luis Barguñó Jané [luisbargu@gmail.com<mailto:luisbargu@gmail.com>]
Sent: 02 August 2017 15:05
To: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
Subject: Geolocation header
Hi,

I would like to discuss with you a proposal to solve the following use case:

Currently, the only mechanism to share your location with a website is through the JS Geolocation API. This has some limitations: First, in order to have the server know the client’s location there are two full roundtrips required (one roundtrip to load the page with Javascript code, and a second roundtrip to actually send the location to the server and get back a location-aware response). While not as significant as the first limitation, the second limitation is that the client must execute Javascript in order to acquire location.

For example, for services like Search, it means that the very first response from a server will contain non-localized results, and a second roundtrip would be required to refresh those results (assuming Geolocation permission is already granted for the origin).

There's many ways to solve this problem through headers, so no JS would be required and clients could proactively include geolocation data in the very first request (after the server asked for it in previous sessions, and permissions are granted).

After an initial thread on GitHub<https://github.com/httpwg/http-extensions/issues/364>, I decided to start here the discussion so it goes through the proper channels.

Here you can find a document detailing the problem and a possible proposal<https://docs.google.com/document/d/1zL4qyOpp6W36H4_eMpmth3Yj_ZTMZ3wCupc01q5qatA/edit>

After a bit of discussion, it looks like Client Hints (CH)<https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04> would be a great way to solve this use case, so I'm preparing a draft for a CH-based approach.

It would be great to get your opinion on this, if this is something that might be interesting for people in this working group, or whether I should start this as an individual draft. Any recommendation?

Thanks!
Luis