Intent to Prototype: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

86 views
Skip to first unread message

David Benjamin

unread,
Mar 31, 2021, 2:47:14 PMMar 31
to blink-dev, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, mike...@chromium.org

Contact emails

aaro...@chromium.org

davi...@chromium.org

b...@chromium.org

jadek...@chromium.org

mike...@chromium.org


Explainer

https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#connection-level-settings


Design doc

https://docs.google.com/document/d/1Eh1iDdjf26_wTrkXseQksj90i55UpYS9jT-auSDHlm8/edit


Specs

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

https://tools.ietf.org/html/draft-vvv-httpbis-alps

https://tools.ietf.org/html/draft-vvv-tls-alps


TAG review

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


Summary

The ACCEPT_CH HTTP/2 and HTTP/3 frames, combined with the TLS ALPS extension, are a connection-level optimization to deliver the server’s Client Hint preferences in time for the first HTTP request.


Motivation

HTTP Client Hints can replace passive fingerprinting surfaces with server-requested (and potentially deniable) client headers. However, the client may have out-of-date information on the server preferences when it sends a request. On the first page load, the client may not know to send any hints at all.


The Critical-CH header allows the server to request a client retry when a header was missing due to out-of-date preferences. The ACCEPT_CH frame is a companion mechanism to avoid the retry in most cases by delivering it as part of connection setup.


Risks

Interoperability and Compatibility

This is a protocol extension, so the compatibility properties are a bit different from a web platform API. The main source of compatibility risk is that details about the design will change as it settles into the final shape. We mitigate this by using different numeric code points in draft ALPS and ACCEPT_CH implementations, so they will not conflict with the final ones. (Unlike web platform APIs, we don’t need to worry about losing a descriptive developer-visible name.)


This is similar to the strategy we successfully used with TLS 1.3.


TLS features are also negotiated, and the ACCEPT_CH frame is an optimization over the existing Critical-CH and Accept-CH HTTP header behavior anyway. That means removing a draft version will not break sites.


Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: No signals


Please include links where possible. Examples include resolutions from relevant standards bodies (e.g. W3C Working Group), tracking bugs, or links to online conversations.


Ergonomics

This API is meant to be used in conjunction with the Critical-CH header, as an optimization to avoid the retry in most cases.


Performance-wise, it doesn’t impose any synchronous API requirements, though we do need to plumb new signals to and from the network service. See design document for details.


Activation

As with other protocol-level extensions, the site’s TLS and HTTP serving software would need to be updated to support this feature. We envision this will follow the usual process for other such changes, such HTTP/2 or TLS 1.3. Over time, it makes its way through the pipeline, it will be easier to adopt. By shipping the ACCEPT_CH frame and the Critical-CH header in parallel, we can provide both a low-friction mechanism in the short-term and this optimization in the long-term.


Debuggability

The effects of the ACCEPT_CH frame will be visible in the DevTools network panel by way of which headers were sent, though we can iterate on this as other use cases come up.


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

Yes


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

No, this will be tested with browser-side tests. TLS-adjacent features are not currently testable by web-platform-tests. See this issue:

https://github.com/web-platform-tests/wpt/issues/20159


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5555544540577792


Requesting approval to ship?

No


Yoav Weiss

unread,
Apr 1, 2021, 4:00:59 AMApr 1
to blink-dev, David Benjamin, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, mike...@chromium.org
Thanks for working on this! This is an enabler for Client Hints as a nextgen content negotiation mechanism.

Reply all
Reply to author
Forward
0 new messages