- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 28 Feb 2023 17:24:41 +0000
- To: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Cc: Momoka Yamamoto <momoka.my6@gmail.com>, Ben Schwartz <bemasc@google.com>, ietf-http-wg@w3.org
- Message-ID: <CALGR9oZYkMAT1r=ngeDujbE8pFRoDfG0qe=Y4YhvNiZjzBmLeg@mail.gmail.com>
Hey Glenn, On Tue, Feb 28, 2023 at 5:03 PM Glenn Strauss < gs-lists-ietf-http-wg@gluelogic.com> wrote: > On Tue, Feb 28, 2023 at 04:12:21PM +0800, Momoka Yamamoto wrote: > > Hello, > > I have submitted a new revision of this > > draft draft-momoka-httpbis-settings-enable-websockets. > > > URL: > > > > https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-websockets-01.txt > > Why should SETTINGS_ENABLE_WEBSOCKETS be added to HTTP/2, HTTP/3, HTTP/X > protocols instead of using existing service discovery mechanisms such as > alt-svc or the proposed alt-svcb? > > https://martinthomson.github.io/alt-svcb/draft-thomson-httpbis-alt-svcb.html The service discovery is decoupled from the service. This means the client has to take a gamble that out-of-band information is in agreement with the active connection. Settings are a means to discover the features of the service's active connection. As discussed upthread, there are other proposals that could put this information in e.g. the DNS. That might help address other problems but is separate from this proposal. > > > There is already SETTINGS_ENABLE_CONNECT_PROTOCOL and the proposed > SETTINGS_ENABLE_WEBSOCKETS would be a specific subset of that. > While websockets is important to many apps, is this subset important > enough to add its own setting to multiple HTTP protocol versions and > to be advertised as part of every single HTTP/2 and HTTP/3 request? > SETTINGS_ENABLE_CONNECT_PROTOTCOL enables the use of the ":protocol: psuedo-header, that's it. This field can contain many vaules, so using it as a signal that the server supports ":protocol: websocket" is a gamble. The gamble potentially gets worse as more protocols get defined and get deployed across the range of HTTP/2 and HTTP/3 protocls: see connect-udp, connect-ip and webtransport. Might there be settings created for other protocols that leverage > SETTINGS_ENABLE_CONNECT_PROTOCOL? Why should a new SETTING be created > for websockets and not for ... ? > Yes, this is already the case for WebTransport over HTTP/2 [1] and WebTransport over HTTP/3 [2], which define a SETTINGS_ENABLE_WEBTRANSPORT. So adding a setting explicitly for WebSocket would make things consistent. Cheers Lucas [1] - https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-04.html#section-3.2 [2] - https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-04.html#section-3.1
Received on Tuesday, 28 February 2023 17:25:05 UTC