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

Reply via email to