Accept-CH-Lifetime support (Intent to Implement)

[Tarun Bansal]

Contact emails

tba...@chromium.org, be...@chromium.org, igri...@chromium.org

 

Spec

https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-6.2

 

Discussion thread:

https://github.com/httpwg/http-extensions/issues/306

 

Summary and Motivation:

Client hints allow the user agent to provide device-specific preferences in the HTTP request headers, which can be used by the server for content negotiation to select appropriate responses. Device’s DPI and viewport size are examples of such configuration data that we support today.

 

As currently implemented, client hints are opt-in and are only sent for subresource requests of a response that provides the explicit opt-in signal, either via Accept-CH response header or equivalent HTML markup. The opt-in preference is not persisted across navigations, and the hints are thus not available on the initial request. This, in practice, severely limits the usefulness of such hints as a lot of the critical negotiation decisions need to be made on the initial request.

 

The client hints spec was recently updated to allow origins to advertise client hints opt-in for a longer duration via the newly defined Accept-CH-Lifetime HTTP response header. The user agent is then expected to persist the advertised preference and provide specified client hints on all subsequent requests to that origin for the specified period.

 

Interoperability and Compatibility Risk:

Low. Opt-in header and extension to Client hints API.

 

Ongoing technical constraints:

None.

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

 

Requesting Approval to Ship?

No.

 

OWP launch tracking bug:
No launch bug because not requesting approval to ship yet.

[PhistucK]

Just so you know (for next time), the subject must be -

Intent to implement: foo

Automated tools are monitoring this exact subject prefix (perhaps case insensitive, not sure, but the colon is required).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c177075-7909-44e8-acb7-cb841f5b9a3f%40chromium.org.

[Tarun Bansal]

Sorry about that. Would it be useful to post a new message thread?

[PhistucK]

Intent to implement threads are less important for those (they monitor not-yet-approved intent threads and intent to implement threads do not require approvals), so I would not bother with this one (especially since you already started two threads ;)).

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36b98cba-275c-4dc2-a363-1f74b4ac15d6%40chromium.org.

[John Mellor]

Would this be reset when clearing cookies?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Kekz93PwPRkTas9Ux4Ke2oY-kGyGYtGHeEhDN%2BhCRfCg%40mail.gmail.com.

[Tarun Bansal]

Yes, the hints for an origin would be cleared if the user clears cookies or disables javascript for that origin.  The hints would be stored per-profile, so clearing cookies or disabling javascript would clear hints stored for only that profile.

[Rick Byers]

Cool, I'm excited about this.  It's been a long-standing problem that we didn't have a reliable solution to client-hits use-cases.  I've heard a bunch of demand from major web properties (and felt the need myself working on GMail) for knowing more about the client in the initial request rather than only via JavaScript later in order to improve page load latency.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8fc5d1cb-0646-4f28-8454-93fb8fc6344d%40chromium.org.

[Anne van Kesteren]

On Thu, Jun 22, 2017 at 2:32 PM, Tarun Bansal <tba...@chromium.org> wrote:
> Spec
>
> https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-6.2

It seems this would also require corresponding changes to Fetch?


--
https://annevankesteren.nl/

[Ilya Grigorik]

On Thu, Jun 29, 2017 at 5:02 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Jun 22, 2017 at 2:32 PM, Tarun Bansal <tba...@chromium.org> wrote:
> Spec
>
> https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-04#section-6.2

It seems this would also require corresponding changes to Fetch?

I think we already have correct logic [1] within the fetch algorithm. However, there is a missing bit there for how "client hint list" [2] is populated, which is what this update is implicitly tackling. We previously said that this will be defined upstream in the IETF doc, but in retrospect.. I don't think that makes sense, as we're missing all the necessary hooks there. If it makes sense to you, I'd propose we integrate this logic as part of Fetch. WDYT?

[1] https://fetch.spec.whatwg.org/#dfnReturnLink-1

[2] https://fetch.spec.whatwg.org/#client-hints-list

 

 

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Thu, Jun 29, 2017 at 12:24 AM, Ilya Grigorik <igri...@google.com> wrote:
> I think we already have correct logic [1] within the fetch algorithm.
> However, there is a missing bit there for how "client hint list" [2] is
> populated, which is what this update is implicitly tackling. We previously
> said that this will be defined upstream in the IETF doc, but in retrospect..
> I don't think that makes sense, as we're missing all the necessary hooks
> there. If it makes sense to you, I'd propose we integrate this logic as part
> of Fetch. WDYT?

Sounds good. Since it's a response header the other part I was
thinking of is defining when it's parsed/handled. In particular
whether it's handled in responses from service workers or only in
responses from the network.

[Ilya Grigorik]

Opened a bug on Fetch, if anyone wants to follow along: https://github.com/whatwg/fetch/issues/566.