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

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?

Yoav Weiss

unread,

Apr 1, 2021, 4:00:59 AM4/1/21

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.

I suspect that on that front, you have some positive signals:

https://twitter.com/Sawtaytoes/status/1369031447940526080

https://twitter.com/_jayphelps/status/1369023028735148032

Reply all

Reply to author

Forward

0 new messages