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/CAKXHy%3DdsBi0z-M7iGD%3DZiOhsM4o%3Djv2oUbooi6QQJs_eD48cBw%40mail.gmail.com.
