W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: New Version Notification for draft-momoka-httpbis-settings-enable-websockets-00.txt

From: Wenbo Zhu <wenboz@google.com>
Date: Wed, 18 Jan 2023 09:47:05 -0800
Message-ID: <CAD3-0rMdB=KD4z0S_+yTc8J03fqiYBApah8NGigikjq4KXF83Q@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Ben Schwartz <bemasc@google.com>, Momoka Yamamoto <momoka.my6@gmail.com>, ietf-http-wg@w3.org
On Wed, Jan 18, 2023 at 9:16 AM Lucas Pardue <lucaspardue.24.7@gmail.com>

> Hi Momoka,
> Thanks for sharing your proposal. If I understand the use case, Dragana
> made a proposal to address some similar problems a little while back [1]
> (albeit solving the problem in a different way). Just in case you didn't
> catch it the first time around, and the discussion thread for that proposal
> probably has some useful background [2].
> I think the value of any solution to this class of problem depends on how
> much pain the decision about what connection to use causes. IHMO that
> mostly comes down to a matter of latency.
> For example, in one case, where a web browser has an HTTP/2 connection
> open to navigate a page, which then leads to a loading a document that
> includes an wss:// URL, by that time the proposed
> SETTINGS_ENABLE_WEBSOCKETS would likely have been received and the browser
> can make an informed choice whether to try to open a WebSocket stream or
> to.
> However, in cases where there is no active connection, then the client is
> going to have to create one and wait for the server SETTINGS before knowing
> what to do. That has latency and is a gamble. Without some client-side
> caching of the server support, it might be a safer gamble to just always
> try HTTP/1.1.
> When WebSockets over H2 was written, I might have agreed that
> SETTINGS_ENABLE_CONNECT_PROTOCOL is a signal the server supports WebSockets
> over H2. But now we're adding multiple :protocol values into the mix with
> MASQUE and WebTransport. Just because a page loaded over my infrastructure
> includes a wss::// URL, it doesn't mean my infrastructure supports it for
> all HTTP versions. For instance, I might theoretically like to roll out
> support for WebTransport and never roll out WebSockets.
> Whether a request can be serviced is a property of the target resource. So
> if I had a server that understood CONNECT but wanted to reject :protocol:
> websocket, then perhaps returning a 405 Method Not Allowed would be more
> appropriate than a 501.
> Which gets me thinking, maybe we should be designing a way for clients to
> query the :protocols supported for a target resource or a server. The
> OPTIONS methods can carry the query, however, the :protocol pseudo-header
> cannot be sent directly in the response, so another header might be
> required - I'd write that up if there's interest.

> If a browser is already making pre-flight OPTIONS requests for a WebSocket
> due to CORS, this approach would seem to align with that.
My understanding is that this is not the case, i.e. no preflight or CORS
for websockets.  I would be interested in the background behind it.

> Cheers
> Lucas
> [1] -
> https://datatracker.ietf.org/doc/draft-damjanovic-websockets-https-rr/
> [2] -
> https://lists.w3.org/Archives/Public/ietf-http-wg/2021OctDec/0052.html
> On Wed, Jan 18, 2023 at 4:22 PM Ben Schwartz <bemasc@google.com> wrote:
>> This draft says
>> Suppose the server supports extended CONNECT but not bootstrapping
>>> WebSockets over that HTTP connection. In this case, the client sending a
>>> WebSocket handshake request will result in a response of 501 (Not
>>> Implemented) status code (Section 15.6.2 of [HTTP]), and the client would
>>> need to fall back to trying the WebSocket handshake over HTTP/1.
>> I don't think this is correct.  If the client encountered this error
>> code, it would just fail the WebSocket setup attempt.
>> In general, I don't think we should be asking clients to retry requests
>> across different HTTP versions.  If you publish wss:// URIs for your
>> domain, you need to support WebSocket on all the domain's HTTP versions.
>> On Wed, Jan 18, 2023 at 10:45 AM Momoka Yamamoto <momoka.my6@gmail.com>
>> wrote:
>>> Hello,
>>> I have submitted an internet-draft proposing a SETTINGS_ENABLE_WEBSOCKETS
>>> settings parameter.
>>> With WebSockets not being the only protocol that uses extended CONNECT (
>>> https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/68#issuecomment-1310323592
>>> ),
>>> Before starting the WebSocket handshake, it will be nice to know if the
>>> server supports bootstrapping WebSockets over HTTP/2 or HTTP/3.
>>> I would love to know your thoughts
>>> Momoka Y
>>> ---------- Forwarded message ---------
>>> From: <internet-drafts@ietf.org>
>>> Date: Sat, Jan 7, 2023 at 6:30 PM
>>> Subject: New Version Notification for
>>> draft-momoka-httpbis-settings-enable-websockets-00.txt
>>> To: Momoka Yamamoto <momoka.my6@gmail.com>
>>> A new version of I-D,
>>> draft-momoka-httpbis-settings-enable-websockets-00.txt
>>> has been successfully submitted by Momoka Yamamoto and posted to the
>>> IETF repository.
>>> Name:           draft-momoka-httpbis-settings-enable-websockets
>>> Revision:       00
>>> Title:          SETTINGS_ENABLE_WEBSOCKETS settings parameter for HTTP/2
>>> and HTTP/3
>>> Document date:  2023-01-07
>>> Group:          Individual Submission
>>> Pages:          5
>>> URL:
>>> https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-websockets-00.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-momoka-httpbis-settings-enable-websockets/
>>> Html:
>>> https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-websockets-00.html
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-momoka-httpbis-settings-enable-websockets
>>> Abstract:
>>>    This document proposes a new HTTP settings parameter,
>>>    SETTINGS_ENABLE_WEBSOCKETS.  This parameter indicates whether the
>>>    server supports bootstrapping WebSockets over the established
>>>    connection.
>>> The IETF Secretariat
Received on Wednesday, 18 January 2023 17:47:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC