- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Tue, 28 Feb 2023 12:50:39 -0500
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Momoka Yamamoto <momoka.my6@gmail.com>, Ben Schwartz <bemasc@google.com>, ietf-http-wg@w3.org
On Tue, Feb 28, 2023 at 05:24:41PM +0000, Lucas Pardue wrote: > > 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. Thanks. ISTR the DNS discussion. I'll go find it in the archives. My point is that this proposal should reference other potential solutions and should discuss pros and cons of this proposal versus other potential solutions, especially solutions that already exist. > 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. > [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 Those are drafts, too. Personally, I remain unconvinced that these should be their own SETTING. At a minimum, I would like to see the drafts highlight that these new SETTINGS are absolutely optional to indicate specific support, meaning that clients can use this information if provided, but SHOULD NOT use absense of this (IMO protocol bloat) information in any way. As an alternative, I would think another extensible service discovery mechanism might be extending OPTIONS responses with additional response headers. Others may choose DNS or to extend /.well-known/. These are existing discovery mechanisms (with their own pros and cons) and might be extended for service discovery as well as protocol feature discovery. SETTINGS_ENABLE_WEBSOCKETS and SETTINGS_ENABLE_WEBTRANSPORT proposals aim to allow protocol feature discovery upon the initial connection and without an additional round trip, and so should highlight why this is of such importance, and why someone using these features is also someone who is visiting the site for the very first time and might not have cached alternate protocol feature discovery from a prior set of connections and requests. If I connect to example.com and attempt websockets over HTTP/3, I can then cache (maybe for a week or so) if it succeeded or failed, and use that for subsequent connections. Cheers, Glenn
Received on Tuesday, 28 February 2023 17:50:59 UTC