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

[Wenbo Zhu <[e-mail]>]

On Wed, Jan 18, 2023 at 9:16 AM Lucas Pardue <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> 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: <[e-mail]>
>>> 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 <[e-mail]>
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>