W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Re: Advertising WebSocket support in the HTTPS resource record

From: Ben Schwartz <bemasc@google.com>
Date: Wed, 20 Oct 2021 13:27:32 -0400
Message-ID: <CAHbrMsDOx+m2Q_4kHiyD9kFeo29b3wpAHWBA6WsGbAcZMwYHww@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Dragana Damjanovic <dragana.damjano@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Oct 20, 2021, 12:54 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
> On Wed, Oct 20, 2021 at 5:35 PM Ben Schwartz <bemasc@google.com> wrote:
>
>>
>> My expectation is that the supported :protocols are handled like the
>> supported paths: the client knows which one it needs from the URI (e.g.
>> wss://..., https://.../foo), and the origin had better support it if it
>> is advertising those URIs anywhere.  I don't think we need a pre-connection
>> hint about the supported :protocols.
>>
>
> I don't follow. That implies the server would present different pages to a
> client based on the protocol that the client connected with.
>

No, I'm trying to say the opposite of that.  These things are properties of
the origin, not any specific endpoint or transport.

...

> If it does, and finds that the server doesn't support the protocol that it
> wants, then the request will fail, and the client wasted its time.
>

Sure.  That's just like a 404, and the solution is the same: don't tell
your users to send requests that your origin doesn't support.

Received on Wednesday, 20 October 2021 17:27:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 20 October 2021 17:27:58 UTC