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

[Ben Schwartz <[e-mail]>]

On Wed, Jan 18, 2023 at 12:14 PM Lucas Pardue <[e-mail]>
wrote:
...

> When WebSockets over H2 was written, I might have agreed that
> SETTINGS_ENABLE_CONNECT_PROTOCOL is a signal the server supports WebSockets
> over H2.
>

(I don't think it ever meant that.)


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

Are you sure?  I think it does.  Or rather, if your infrastructure does not
support WebSocket for all its HTTP versions, then wss:// URLs that point to
your infrastructure are not valid.


> For instance, I might theoretically like to roll out support for
> WebTransport and never roll out WebSockets.
>

That's fine, and has nothing to do with this.  However, you can't roll out
WebTransport only on HTTP/X, and not on HTTP/Y, if your system offers both
HTTP/X and HTTP/Y.  You have to roll it out on all versions before
customers are allowed to use it.

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

I don't think this will work.  Regardless of how the error is reported (via
SETTINGS or via an HTTP error code), there is no requirement (e.g. in RFC
8441) that clients respond to an error by retrying a WebSocket setup using
a different HTTP version, even if some clients today have some degree of
fallback behavior.

In the general case, this would be sheer madness.  For example, if I try
WebTransport over HTTP/2, but the server says
SETTINGS_ENABLE_CONNECT_PROTOCOL is not supported, should I retry it over
HTTP/1.1 or  HTTP/3?


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