I’m also wondering why https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits 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 <david...@chromium.org> wrote: > > Hi Alex, thanks for the comments! Responses inline. > > On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen <achristen...@apple.com > <mailto:achristen...@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#why-two-mechanisms > > <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#retry-limits > > <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 > > <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#connection-level-settings > > > > <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> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev