Intent to Ship: Critical-CH, a Client Hint reliability mechanism

[Aaron Tagliaboschi]

Contact emails

aaro...@chromium.org, mike...@chromium.org, jadek...@chromium.org, yoav...@chromium.org

Explainer

https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md

Specification

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-00

Design docs

https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md

Summary

Adds support for a new HTTP response header, Critical-CH to indicate that if a particular Client Hint header was not received and could have been sent, a new request should be made that includes the particular Client Hint header.

Blink component

Privacy

Search tags

Client Hints

TAG review

https://github.com/w3ctag/design-reviews/issues/549

TAG review status

Pending

Risks

Interoperability and Compatibility

Compatibility This change is a no-op for servers that don’t send the Critical-CH response header, and shouldn’t pose a compatibility risk for older browsers or browsers that don’t support the header. This feature still allows for the possibility of lack of support from the browser side, which means that sites shouldn’t need to treat other browsers any differently if they do or don’t support it. Interoperability There’s generally neutral feelings for Client Hints and the related proposals from other browser vendors. Safari is generally neutral without an official stance and Firefox maintains a “non-harmful” position on Client Hints and UA Client Hints. Edge, however, has been publicly supportive. There have also been positive signals from other browsers about the potential impacts of the UA Client Hints proposal.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/479)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html)

Edge: Positive (https://groups.google.com/a/chromium.org/g/blink-dev/c/zPYGbULXn7o/m/q3OJ2kZAAQAJ)

Web developers: No signals

Ergonomics

Utilizing the Critical CH response header will mean an additional request/response round trip, especially on first-time navigations to the site and after a change in Client Hint preferences. It is up to the developer to decide if the need for the information on the first navigation request is worth “paying” the cost of extra requests. It should be noted that, unless the majority of a site's traffic is first-time navigations, a retry should be relatively rare. The lifetime of client hint preferences is the browser session, which is generally fairly long lived. Much of these situations will be resolved by the other side of the larger Client Hint Reliability proposal, which puts the client hint negotiation into the HTTP/2, HTTP/3, and TLS handshakes, before the first navigation.

Activation

This feature was designed to be low-friction for developers. Like the Accept-CH response header, this can be a static configuration in HTTP server software and sent with all responses.

Debuggability

The secondary request and response should be visible in DevTools. I don’t think there will need to be any active work.

Is this feature fully tested by web-platform-tests?

Yes: (http://wpt.fyi/results/client-hints/critical-ch)

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1127313

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1170725

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5727177800679424

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/zPYGbULXn7o

This intent message was generated by Chrome Platform Status.

[Daniel Bratell]

I could not see anything about requests that have side-effects. Will PUT/POST also be retried if they happen to receive a critical-ch header with no previously cached such response from the server? Should they?

/Daniel

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4Xb9vFCboXT1cFRb1LmtdDOD7rSWT89DEJn0-%3Dqr50ePag%40mail.gmail.com.

[David Benjamin]

PUT/POST will not be retried. I don't think they should because, yeah, side effects.

   1.  If the request did not use a safe method (Section 4.2.1 of
       [RFC7231]), ignore the Critical-CH header and continue processing
       the response as usual.
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02#section-3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c801682-9f47-eb91-474f-7724ee957a8d%40gmail.com.

[Chris Harrelson]

Hi,

Two more questions:

- The TAG raised a point regarding responding to a 200 with a redirect seeming odd - did that particular point get discussed in the IETF?

- As I understand it, there is another feature being worked on that will allow sites to avoid an extra round-trip to the server by integrating critical hints into the connection negotiation process. Is there a good reason not to wait and ship the two features together, so that we can avoid a situation where extra round trips get added, even if temporarily?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaBXAC5OB5UOMTGtOu8x0AFP4wchbdhfWZu2G57bW%3DiQ_g%40mail.gmail.com.

[Aaron Tagliaboschi]

You're right it's not in the explainer but it is in the specification:

>  1. If the request did not use a safe method (Section 4.2.1 of [RFC7231]), ignore the Critical-CH header and continue processing the response as usual.

and the implementation

Aaron Tagliaboschi | Software Engineer, Chrome Trust & Safety

On Thu, Mar 11, 2021 at 3:25 PM Daniel Bratell <brat...@gmail.com> wrote:

[Aaron Tagliaboschi]

- As I understand it, there is another feature being worked on that will allow sites to avoid an extra round-trip to the server by integrating critical hints into the connection negotiation process. Is there a good reason not to wait and ship the two features together, so that we can avoid a situation where extra round trips get added, even if temporarily?

That's correct; we're creating a new H2/3 frame (ACCEPT_CH) and hooking it into ALPS, both of which you can read about in the intent to prototype just published <https://groups.google.com/a/chromium.org/g/blink-dev/c/DJEygGmiSz4>

We do in fact plan on shipping both of these features together.

[Daniel Murphy]

I'm a fan because this enables better server-side-rendering for webapps - see https://github.com/w3c/manifest/issues/954.

Having this shipped allows websites to rely on this hint more for server-side rendering.

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4XbpUTLQUDVGp2tRAoRtN_H_L%3DGXkVcn_eZP0HRAp19DMA%40mail.gmail.com.

[Chris Harrelson]

Hi, sorry for the delays; I meant to send this email last Thursday.

LGTM1 to ship this as long as it's done together with "ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames". At the API owners meeting last week, we agreed this would be ok generally, but please wait for 2 more LGTMs before it's official.

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

[David Benjamin]

Ah yeah, that's the intent (hah). Sorry that the second I2S took so long to get out. :-( To answer your other question from earlier:

> The TAG raised a point regarding responding to a 200 with a redirect seeming odd - did that particular point get discussed in the IETF?

The overall draft got discussed at the IETF. The point didn't come up but I don't think it'd occurred to anyone, myself included, that there was anything odd here to make a point out of it. :-) (TAG review discussion came later.) It's just a retried request. From the perspective of HTTP, it's just a second request that happens to look similar to the first. There are plenty of other contexts where requests get retried, including browser reload, Retry-After, 425 Too Early, 0-RTT rejection, HTTP auth, etc.

RFC7231 even discusses, in vague terms, "reactive negotiation" flows where the UA can choose alternate forms of a resource based on some unspecified information from the server. In some sense, all the work around Client Hints is to finally instantiate that idea concretely. :-)
https://tools.ietf.org/html/rfc7231#section-3.4.2

[Daniel Bratell]

What Chris said. LGTM2 given the assumption that this will ship with the related technologies.

/Daniel

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/245d86a2-671a-a6e3-c3bf-912f011dc0cb%40gmail.com.