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

243 views
Skip to first unread message

David Benjamin

unread,
Apr 6, 2021, 4:25:01 PM4/6/21
to blink-dev, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor

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


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 before the first HTTP request.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/DJEygGmiSz4


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

Yes


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.


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 API, 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: Pending https://github.com/mozilla/standards-positions/issues/510
Safari: Pending https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html

Web / Framework developers: https://twitter.com/Sawtaytoes/status/1369031447940526080 https://twitter.com/_jayphelps/status/1369023028735148032


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.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

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


Entry on the feature dashboard

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


Mike West

unread,
Apr 8, 2021, 1:47:15 PM4/8/21
to David Benjamin, blink-dev, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor
LGTM1.

The TAG review seems stalled since January; I pinged it. The webkit-dev@ thread seems to be going in a good direction, and internal security/privacy review has approved the design as well. If our friends at Mozilla (or elsewhere!) give you feedback that would influence the design, please take it into account before shipping.

-mike


--
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/CAF8qwaCtQec_7BBHh0Q92%2BTEB98-m6UdavQfb6ps%3DM_zPKP7jg%40mail.gmail.com.

Chris Harrelson

unread,
Apr 8, 2021, 2:47:59 PM4/8/21
to Mike West, David Benjamin, blink-dev, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor

Alex Russell

unread,
Apr 8, 2021, 3:21:34 PM4/8/21
to blink-dev, Chris Harrelson, David Benjamin, blink-dev, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor, Mike West
LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

Yoav Weiss

unread,
Apr 8, 2021, 3:42:25 PM4/8/21
to blink-dev, Alex Russell, Chris Harrelson, David Benjamin, blink-dev, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor, Mike West
Since developer signals are now mandatory and this particular signal is somewhat vague ("we want it" but without clearer explanation as to why), I dug up a Twitter thread from a day earlier that better outlines the intended use.
For background, Jay is working on Edge-side rendering of React apps, which is where Viewport-Width and other client hints can come in handy as part of the HTML creation process.

PhistucK

unread,
Apr 11, 2021, 8:46:29 AM4/11/21
to Yoav Weiss, blink-dev, Alex Russell, Chris Harrelson, David Benjamin, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor, Mike West
To clarify, "Edge-side" is not Microsoft Edge. :)

PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

--
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/ba86035f-2911-44ec-acee-2acec8e071b3n%40chromium.org.

Yoav Weiss

unread,
Apr 11, 2021, 10:33:51 AM4/11/21
to PhistucK, blink-dev, Alex Russell, Chris Harrelson, David Benjamin, Aaron Tagliaboschi, Bence Béky, jadek...@chromium.org, Mike Taylor, Mike West
Indeed! I was talking about CDN edge servers
Reply all
Reply to author
Forward
0 new messages