LGTM3 On Thursday, January 20, 2022 at 5:23:25 PM UTC+1 Mike West wrote:
> I see. Thanks for the additional detail! > > This still LGTM2, though. As you note, this brings us closer to what other > vendors are doing, and a better solution is going to require some new > agreement between folks about how to handle the set of servers you're > pointing at. Implementing that sounds like it would reasonably be > considered a separate intent. > > -mike > > > On Thu, Jan 20, 2022 at 4:58 PM David Benjamin <david...@chromium.org> > wrote: > >> Well, there is, alas, still a difference because HTTP/2 + WebSockets is >> complicated. But less of one at least. :-) >> >> (WebSockets support wasn't part of HTTP/2, and HTTP/3 for that matter, >> from the beginning. That means we can't be sure an HTTP/2-supporting server >> doesn't also support WebSockets, yet predate RFC 8441, and thus expect us >> to drop HTTP/2 for wss requests. So while we implement RFC 8441, it only >> kicks in if we happen to already have a suitable HTTP/2 connection on-hand. >> If we have to make a new connection, we drop HTTP/2 and only offer >> HTTP/1.1. Possibly something fancier ought to be done here, be it >> out-of-band signaling, defining an "h2+wss" ALPN, some kind of fallback >> like Firefox does, racing two connections, or whatever else. This Intent >> would be a prerequisite to doing that, but leaves the question for later.) >> >> On Thu, Jan 20, 2022 at 5:49 AM Mike West <mk...@chromium.org> wrote: >> >>> LGTM2. From a Fetch perspective, there shouldn't be a difference between >>> the way we establish a Web Socket connection and regular ol' HTTP requests. >>> Aligning our behavior with other vendors in this respect is appreciated! >>> >>> -mike >>> >>> >>> On Thu, Jan 20, 2022 at 12:22 AM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> LGTM1, thanks for improving interop here. >>>> >>>> On 1/19/22 3:22 PM, David Benjamin wrote: >>>> >>>> Contact emails david...@chromium.org >>>> >>>> Specification https://datatracker.ietf.org/doc/html/rfc7301 >>>> >>>> Summary >>>> >>>> This is a PSA about a small tweak to an existing feature. The change is >>>> to include the TLS ALPN extension when initiating a new connection for >>>> wss-schemed WebSockets, offering just the default "http/1.1" protocol. >>>> Currently, unlike HTTPS connections, such connections do not offer ALPN in >>>> Chrome at all. Changing this aligns with Firefox and Safari, hardens >>>> against cross-protocol attacks (see ALPACA), and makes wss eligible for >>>> the >>>> False Start optimization. It also simplifies work on the HTTPS DNS record. >>>> >>>> >>>> Blink component Internals>Network>SSL >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>> >>>> TAG review status Not applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> Interoperability risk is low. Firefox and Safari are already both >>>> offering ALPN for WebSockets requests, as does Chrome for HTTPS requests. >>>> This change does not impact the HTTP version we use for WebSockets itself, >>>> nor does it require servers to implement ALPN. Whether the server accepts >>>> ALPN or not, we will continue to speak WebSockets over HTTP/1.1. >>>> >>>> >>>> Gecko: Shipped/Shipping (Firefox appears to actually initially offer >>>> both "h2" and "http/1.1". Then, if it finds an HTTP/2 server without RFC >>>> 8441 support, it retries, only offering "http/1.1". Either way, it always >>>> offers ALPN.) >>>> >>>> WebKit: Shipped/Shipping (Confirmed via Wireshark) >>>> >>>> Web developers: No signals >>>> >>>> Other signals: >>>> >>>> >>>> Debuggability >>>> >>>> Existing DevTools support for networking and WebSockets applies >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> n/a >>>> >>>> Requires code in //chrome? False >>>> >>>> Estimated milestones >>>> >>>> Chrome 100, as 99 is just about to branch >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5687059162333184 >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaA1Y_GZDk0qNc_%3DhVLhye%3DScEtxjPSdEPD-mM4zpVp50Q%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaA1Y_GZDk0qNc_%3DhVLhye%3DScEtxjPSdEPD-mM4zpVp50Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26bac4d2-1d15-5ef5-d917-6ce7411ef6d3%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26bac4d2-1d15-5ef5-d917-6ce7411ef6d3%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/65187a49-a5e3-4e55-9ed2-830e868fd3a7n%40chromium.org.
