Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames
I’m also wondering why https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... says it should only retry GET requests. Is that just to avoid re-uploading large POST requests?
On Apr 6, 2021, at 10:02 AM, David Benjamin <davidben@chromium.org> wrote:
Hi Alex, thanks for the comments! Responses inline.
On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen <achristensen@apple.com <mailto:achristensen@apple.com>> wrote: 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.
Well, with regards to cross-site tracking, I'll note that Accept-CH cache is already naturally partitioned because it only applies to top-level loads. Subresources follow a delegation model. But, yeah, one of the nice outcomes of Client Hint Reliability is it makes the Accept-CH cache actually a cache, so the UA can scope or clear it with less worry. I think reducing the performance and functionality gap between new and returning clients is generally valuable for this sort of thing. I hope Client Hint Reliability is useful in this regard.
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... <https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms>
I think you may have misunderstood the reference to two mechanisms. The TLS ALPS extension and h2/h3 frames are part of the same mechanism. It's a layering thing. TLS provides a generic spot to stick protocol-specific settings early enough in the handshake, and then HTTP/{2,3} define how to use it. (We don't want every new feature like this to require an update to the TLS server.)
Rather, the reference is to (1) Critical-CH HTTP response header and (2) TLS ALPS + h2/h3 frames. I'd love to avoid the redundancy, but I think this is the best option given all the design constraints. And yeah the explainer discusses why.
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.
I'm not sure I'm parsing this sentence right. It sounds like you both don't think server software changes are a good requisite, but also don't think it's good to have a mechanism with lower server software requirements? Oops! Remove the first “don’t” in my sentence.
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?
Sites don't really work that way architecturally. You may have, for instance, a CDN frontend handling TLS and H2/H3, but it contacts the origin server that developers actually upload content to. In such deployments, there usually isn't a way to signal an update to all connections like that. Moreover, there's a race condition here. The client may request the resource at the same time as the server signaling the new preferences.
Wildcard subdomains in the certificate is an interesting problem.
I'll add that cross-name pooling further complicates any hope of signaling existing connections above.
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?
Agreed it should be well-defined. I touched on this briefly in draft-davidben-http-client-hint-reliability-02, but not in full detail. The IETF and W3C/WHATWG split is a bit fun at the boundaries of the web platform and network protocols. :-) I think we'll probably put the full Fetch integration in https://github.com/WICG/client-hints-infrastructure <https://github.com/WICG/client-hints-infrastructure>, alongside the other Client Hints bits.
The interaction we think works best is that ALPS/frames and Accept-CH/Critical-CH are conceptually two separate sources of hint requests, with the expectation that the former is an optimization for the latter. You end up roughly unioning them. This avoids weird behaviors when they mismatch and meshes well with the constraints that led to two mechanisms in the first place.
In https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... <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... <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?
Good question. While they're both "infinite loops", they're not really analogous. I think you want to look at what kinds of problems can lead to infinite loops (how likely are they), and what are the consequences of detecting one (how bad is it).
Imagine the server-trigger retry. To make sure we're on the same page, by server-triggered retry, I mean server-side logic implements something like:
if (RequestNeedsRetry()) { return SelfRedirect(); } else { return ActualResponse(); }
The tricky part here is RequestNeedsRetry(). Suppose a privacy-conscious user has configured their browser to never send the Foo-Bar hint. Or suppose the browser just predates the Foo-Bar hint and doesn't implement it. Our desired outcome is the server gets the Foo-Bar hint if and only if the browser would have sent it when requested. That is a more complex query than checking if the header is present, and it's one every site would need to implement. If any site gets it wrong, they will return SelfRedirect() instead of ActualResponse() and privacy-conscious users infinite loop. The browser will detect it, but the page will simply fail to load because we never got a response.
In comparison, consider Critical-CH. The server unconditionally sends a perfectly fine response, but says, "by the way, I can give you a better response, if you're willing to send me these hints". The browser can then decide whether to use the response as-is, or request a new one. The server needs no interesting logic, it's just static declaration of this resource's properties. If the server goes out of its way to misbehave (or we retry at the same time as a resource update), it can incrementally add one header at a time and trigger lots of retries. But the browser can detect this and just use the resource as-is.
(Come to think of it, it's not even an infinite loop. Each retry must add at least one new header and there are a finite number of headers the server will request. Still, I think the browser should notice this and only retry once.)
So we have one mechanism which makes it very likely that sites will accidentally break for privacy-conscious setups, and we have another which is much easier to get right and, either way, the site still works. I think there's a clear winner here. :-)
On Apr 5, 2021, at 4:32 PM, Mike Taylor via webkit-dev <webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>> wrote:
Hi there,
Complimentary to https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html <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 <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-httpbis-alps> https://tools.ietf.org/html/draft-vvv-tls-alps <https://tools.ietf.org/html/draft-vvv-tls-alps> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... <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 <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
On Tue, Apr 6, 2021 at 2:37 PM Alex Christensen <achristensen@apple.com> wrote:
I’m also wondering why https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md... says it should only retry GET requests. Is that just to avoid re-uploading large POST requests?
POST requests are not safe <https://tools.ietf.org/html/rfc7231#section-4.2.1> or idempotent <https://tools.ietf.org/html/rfc7231#section-4.2.2>, so the client shouldn't automatically resend them. Though, yes, large POST bodies would also be a nuisance.
On Apr 6, 2021, at 10:02 AM, David Benjamin <davidben@chromium.org> wrote:
Hi Alex, thanks for the comments! Responses inline.
On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen <achristensen@apple.com> wrote:
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.
Well, with regards to cross-site tracking, I'll note that Accept-CH cache is already naturally partitioned because it only applies to top-level loads. Subresources follow a delegation model. But, yeah, one of the nice outcomes of Client Hint Reliability is it makes the Accept-CH cache *actually* a cache, so the UA can scope or clear it with less worry. I think reducing the performance and functionality gap between new and returning clients is generally valuable for this sort of thing. I hope Client Hint Reliability is useful in this regard.
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 think you may have misunderstood the reference to two mechanisms. The TLS ALPS extension and h2/h3 frames are part of the same mechanism. It's a layering thing. TLS provides a generic spot to stick protocol-specific settings early enough in the handshake, and then HTTP/{2,3} define how to use it. (We don't want every new feature like this to require an update to the TLS server.)
Rather, the reference is to (1) Critical-CH HTTP response *header* and (2) TLS ALPS + h2/h3 frames. I'd love to avoid the redundancy, but I think this is the best option given all the design constraints. And yeah the explainer discusses why.
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.
I'm not sure I'm parsing this sentence right. It sounds like you both don't think server software changes are a good requisite, but also don't think it's good to have a mechanism with lower server software requirements?
Oops! Remove the first “don’t” in my sentence.
Ah. :-) I think the other constraints are more fundamental. I view this more as a nice bonus. Especially given how slowly TLS sadly moves in much of the ecosystem. Features in TLS libraries, software releases, those releases making their way into Linux distros, and then to LTS versions of those distros, etc. In particular, the rest of Client Hints works with just headers, so having Critical-CH makes it easier for sites to get reliability. That, in turn, reduces the functionality gap when the UA needs to clear or scope some state, as we talked about above. (Though the connection-level optimization is still needed to close the performance gap.)
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?
Sites don't really work that way architecturally. You may have, for instance, a CDN frontend handling TLS and H2/H3, but it contacts the origin server that developers actually upload content to. In such deployments, there usually isn't a way to signal an update to all connections like that. Moreover, there's a race condition here. The client may request the resource at the same time as the server signaling the new preferences.
Wildcard subdomains in the certificate is an interesting problem.
I'll add that cross-name pooling further complicates any hope of signaling existing connections above.
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?
Agreed it should be well-defined. I touched on this briefly in draft-davidben-http-client-hint-reliability-02, but not in full detail. The IETF and W3C/WHATWG split is a bit fun at the boundaries of the web platform and network protocols. :-) I think we'll probably put the full Fetch integration in https://github.com/WICG/client-hints-infrastructure, alongside the other Client Hints bits.
The interaction we think works best is that ALPS/frames and Accept-CH/Critical-CH are conceptually two separate sources of hint requests, with the expectation that the former is an optimization for the latter. You end up roughly unioning them. This avoids weird behaviors when they mismatch and meshes well with the constraints that led to two mechanisms in the first place.
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?
Good question. While they're both "infinite loops", they're not really analogous. I think you want to look at what kinds of problems can lead to infinite loops (how likely are they), and what are the consequences of detecting one (how bad is it).
Imagine the server-trigger retry. To make sure we're on the same page, by server-triggered retry, I mean server-side logic implements something like:
if (RequestNeedsRetry()) { return SelfRedirect(); } else { return ActualResponse(); }
The tricky part here is RequestNeedsRetry(). Suppose a privacy-conscious user has configured their browser to never send the Foo-Bar hint. Or suppose the browser just predates the Foo-Bar hint and doesn't implement it. Our desired outcome is the server gets the Foo-Bar hint if and *only if* the browser would have sent it when requested. That is a more complex query than checking if the header is present, and it's one every site would need to implement. If *any* site gets it wrong, they will return SelfRedirect() instead of ActualResponse() and privacy-conscious users infinite loop. The browser will detect it, but the page will simply fail to load because we never got a response.
In comparison, consider Critical-CH. The server *unconditionally* sends a perfectly fine response, but says, "by the way, I can give you a better response, if you're willing to send me these hints". The browser can then decide whether to use the response as-is, or request a new one. The server needs no interesting logic, it's just static declaration of this resource's properties. If the server goes out of its way to misbehave (or we retry at the same time as a resource update), it can incrementally add one header at a time and trigger lots of retries. But the browser can detect this and just use the resource as-is.
(Come to think of it, it's not even an infinite loop. Each retry must add at least one new header and there are a finite number of headers the server will request. Still, I think the browser should notice this and only retry once.)
So we have one mechanism which makes it very likely that sites will accidentally break for privacy-conscious setups, and we have another which is much easier to get right and, either way, the site still works. I think there's a clear winner here. :-)
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
participants (2)
-
Alex Christensen
-
David Benjamin