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#why-two-mechanisms
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#retry-limits
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#server-triggered-retry
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#connection-level-settings
>
> thanks,
> Mike
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
