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.
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.
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.
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.
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.
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)?
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:
Link to entry on the feature dashboard
Requesting approval to ship?