I’m glad to see ALPS and bytes sent over the network used instead of additional reliance on state on the client. We don’t want to introduce a super cookie on the client, and we want to minimize breakage when a user agent decides to remove state to prevent tracking. I can’t say I’ve followed this development closely or even thought through it all completely, but here are some initial thoughts: My first thought is that it seems excessive to have a way to specify support of client hints both in the TLS handshake and in HTTP/{2,3} frames. I guess that’s why you wrote https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... I don’t think that requiring a site to be running software that supports client hints is a good prerequisite to using client hints, so I don’t think that’s a good reason to have two mechanisms. Sites can change with open connections, but if a site changes its client hints acceptance, wouldn’t that be a good reason to terminate all the open connections and require renegotiation? Wildcard subdomains in the certificate is an interesting problem. If it is decided that multiple mechanisms are necessary, their interaction should be well defined. What if the server said one thing in ALPS but said something different in an HTTP/{2,3} frame? What if I have multiple connections open to the same server and get different client hint headers? In https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... you specify that a client should not retry more than once per request to avoid infinite loops, but in https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... you use the possibility of infinite loops as a reason that a server-triggered retry isn’t a good solution. I think a server-triggered retry is a good solution and we should be able to expect that if someone wants their website to work, then they will do what it takes to make their servers work correctly. Don’t we have the possibility of infinite redirects today?
On Apr 5, 2021, at 4:32 PM, Mike Taylor via webkit-dev <webkit-dev@lists.webkit.org> wrote:
Hi there,
Complimentary to https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html, Chromium intends to ship the ALPS + ACCEPT_CH HTTP/2 and HTTP/3 frames portions of the Client Hints reliability proposal, and we would like to solicit WebKit's position.
As mentioned in the linked thread, the Client Hint Reliability proposal is a set of features aimed at making Client Hints more reliably available and mitigating mis-matches between a site's preferences and the preferences stored in the browser.
In particular, 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.
Specifications:
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability (section 4) https://tools.ietf.org/html/draft-vvv-httpbis-alps https://tools.ietf.org/html/draft-vvv-tls-alps https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md...
thanks, Mike _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev