W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2018

Re: My question about client hints

From: Ilya Grigorik <ilya@igvita.com>
Date: Mon, 26 Mar 2018 22:04:26 -0700
Message-ID: <CAKRe7JFn7fb=Vx+ad7eAc5XMPiMstKS-z1munCjPB9wNpyHx7A@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: Eric Rescorla <ekr@rtfm.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Ilya Grigorik <igrigorik@google.com>, Alex Russell <slightlyoff@google.com>
Both Kenji and Yoav hit on the key points already, so I'll try to keep it
brief.. :)

CH intro provides a high-level overview of the limitations of current
approaches:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-05#section-1

The main limitations of cookie-based approaches are:

   - Doesn't work for dynamic variables. A few examples..
      - "Width" to communicate desired image width
      - "Viewport-Width" can change too: split screen views, browser resize
      on desktop, etc.
      - "ECT", "RTT", "Downlink" are based on recent observed mesurements
      - "Save-Data" is subject to user toggle / preference
      - ... etc., virtually every interesting hint requires cooperation
      from the browser / has dynamic values.
   - Cookies have a number of other limitations
      - Vary + Cookie.. good luck
      - It's a free-for all in terms of names an syntax: good luck on
      interop.
      - Doesn't work for 3P origins — e.g. if you're a CDN for static
      content, good luck getting the cookies set in the first place,
you now also
      need JS executing in 1P context.

CH address the above by defining a simple framework for how interoperable
hints should be specced, negotiated between client and origin, and
implemented by the browser (in upstream specs :)).

On Tue, Mar 20, 2018 at 10:53 AM, Yoav Weiss <yoav@yoav.ws> wrote:

>
> A few things that a cookie cannot cover:
> * On the first page load, CH would give you hints for all the subresources
> of the page, whereas a JS basde solution would be racy and is likely to
> miss many of the subresources which loading started before that JS actually
> ran. As Alex mentioned, all browsers have some form of a preloader, which
> is likely to discover and request those resources before the cookie is set.
> * Cookies cannot cover image specific `width` values, which CH can given
> that this information is available in HTML.
> * Cookies cannot cover 3rd party resources, which CH did support. This
> support was currently removed, but would be reinstated once Feature-Policy
> enables a mechanism for the 1st party to opt in to expose hints to specific
> 3rd parties.
>
>
> On Tue, Mar 20, 2018 at 6:32 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>> At today's session I asked the following question:
>>
>> Given that you can only send client hints if the site could run JS and
>> set a cookie, then
>> why can't the site just run JS on first contact, extract this data, and
>> store it in a cookie,
>> at which point it is available on all previous contacts.
>>
>> As far as I can tell, the only difference here is on first contact. What
>> am I missing.
>>
>> -Ekr
>>
>>
Received on Tuesday, 27 March 2018 05:05:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:13 UTC