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

[Lucas Pardue <[e-mail]>]

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.

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
>>
>>
>>