Contact emailsdavid...@chromium.org
Specificationhttps://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
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 t
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 wrote:
> LGTM1, thank
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, ye
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
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 ab