In our OWNERS meeting this week, there was some confusion on what's
being proposed here (which is understandable, this isn't quite a typical
intent for web exposed feature). Here's a summary of what we're trying
to accomplish:
1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in
M96, which relies on the TLS ALPS protocol extension.
2) There are 2 parts to this: the client being able to understand
ALPS/ACCEPT_CH (and in return do something useful), and the server being
able to send it.
3) Because of a (long fixed) bug present in Chromium's implementation,
it's risky for a server to send too much data via ACCEPT_CH, so it's
usefulness is potentially limited.
4) In order to guarantee that older clients don't have this bug, we
propose to rev the version (aka, code point) at the protocol layer. This
way, if a server sends the new code point and the client understands it,
it can send a larger payload without triggering the bug (which may
result in sad things like a connection being refused).
5) This is sort of web observable, but right now if servers that support
the old code point continue to send the old code point - nothing will
break. Chromium will support both for now, with hopes to deprecate and
remove the older one in the future when we're confident it won't result
in performance regressions for servers sending ACCEPT_CH (since this is
a performance optimization).
I hope that helps clear it up, and I'm sure Victor or David will chime
in if I'm getting something wrong. :)
And to be clear - this isn't a request for a deprecation or removal
(yet), but for shipping the new code point.
On 1/17/24 11:16 AM, Victor Tan wrote:
If the server received the new code point, while it doesn't support,
the ALPS extension will ignore. This also mean client might not know
the server's client hints preferences before the first request.
Currently, only few sites using the ALPS extension. As TLS extension
is negotiated, the server need to support both code points during the
transition period, after some time, the server can drop the old one.
On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote:
On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:
Contact emails
victor...@chromium.org <mailto:victor...@chromium.org>,
miketa...@chromium.org <mailto:miketa...@chromium.org>,
david...@chromium.org <mailto:david...@chromium.org>
Explainer
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md
<https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md>
Specification
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability
<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-httpbis-alps>
https://tools.ietf.org/html/draft-vvv-tls-alps
<https://tools.ietf.org/html/draft-vvv-tls-alps>
Summary
Shipping a new code point (17613) for TLS ALPS extension to
allow adding more data in the ACCEPT_CH HTTP/2 and HTTP/3
frame. The ACCEPT_CH HTTP/2 frame with the existing TLS ALPS
extension code point (17513) had an arithmetic overflow bug
<https://crbug.com/1292069>in the Chrome ALPS decoder. It
limits the capability to add more than 128 bytes data (in
theory, the problem range is 128 bytes to 255 bytes) to the
ACCEPT_CH frame. With the new ALPS code point, we can fully
mitigate the issue.
Blink component
Blink>Network>ClientHints
<https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C&can=2>
TAG review
https://github.com/w3ctag/design-reviews/issues/549
<https://github.com/w3ctag/design-reviews/issues/549>
TAG review status
Closed
Risks
Interoperability and Compatibility
This is switching to a new code point for the TLS ALPS
extension. It won’t change the design of ALPS and ACCEPT_CH
mechanism implementation. The main source of compatibility
risk is that it causes conflicts with ALPS negotiation since
some clients could still use the old code point while others
are switching to use the new code point. The ALPS extension
could be ignored if the code point doesn’t match during
negotiation, which means the server's client hints preferences
won’t be delivered in the ACCEPT_CH HTTP/2 and HTTP/3 frame.
We mitigate this by enabling servers to support both code
points, monitoring both code points usage and removing the old
ALPS code point support in a future intent once the usage is
low enough. We also split the rollout into two phases: we
first start to enable the new ALPS code point for ACCEPT_CH
with HTTP/3 frame in a slow rollout, and then eventually
enable the new code point with HTTP/2 frame.
Does the server have an indication if the client in question
supports the newer code point?
If not, what would we expect servers that support the newer code
point to do?
Edge: No signals
Firefox: Pending
https://github.com/mozilla/standards-positions/issues/510
<https://github.com/mozilla/standards-positions/issues/510>Safari:
Pending
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html
<https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html>
Web/Framework
developers:https://twitter.com/Sawtaytoes/status/1369031447940526080
<https://twitter.com/Sawtaytoes/status/1369031447940526080>https://twitter.com/_jayphelps/status/1369023028735148032
<https://twitter.com/_jayphelps/status/1369023028735148032>
Activation
The site’s TLS and HTTP serving application would need to be
updated to support this new code point. We aren’t aware of
many sites using this feature yet, however.
Debuggability
No special DevTools support needed. The effects of the code
point change of ACCEPT_CH frame will be visible in the
DevTools’ network tab. Also, the NetLog will record the
ACCEPT_CH frame value if TLS ALPS extension is negotiated
successfully.
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
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
No, this feature is tested with browser-side tests. We can’t
test TLS-adjacent features currently through
web-platform-tests. See this issue:
https://github.com/web-platform-tests/wpt/issues/20159
<https://github.com/web-platform-tests/wpt/issues/20159>
Flag name
UseNewAlpsCodepointHttp2
UseNewAlpsCodepointQUIC
Tracking bug
b/289087287 <http://b/289087287>
Launch bug
https://launch.corp.google.com/launch/4299022
<https://launch.corp.google.com/launch/4299022>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5149147365900288
<https://chromestatus.com/feature/5149147365900288>
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org.
