Re: Advertising WebSocket support in the HTTPS resource record

On Fri, Oct 22, 2021 at 6:34 PM Ben Schwartz <bemasc@google.com> wrote:

>
>
> On Fri, Oct 22, 2021 at 3:06 AM Martin Thomson <mt@lowentropy.net> wrote:
> ...
>
>> We could do as you suggest, but that forces an origin that deploys a
>> given protocol version to support all of its resources - and the ways in
>> which those resources operate - over that version as well.
>>
>> That's fine in principle, but - as of this moment - that is an impossible
>> requirement to fulfill.  Websockets over HTTP/3 is a twinkling in the eye
>> of its parents and - by all practical measures - does not exist.
>>
>
> Yes.  I think WebSockets is a special case, though.
>
>
>> This pattern will continue as long as we continue to invent "X over HTTP"
>> with weird interaction methods (think WebTransport and MASQUE).
>
>
> I don't think WebTransport or MASQUE will have these problems.  They'll
> both be defined (or explicitly not defined) for all existing HTTP versions
> on Day 1.  Similarly, any future HTTP versions can incorporate (or
> explicitly reject) all pre-existing protocols.
>
>
I am not sure here. The fallback for WebTransport is not finalize yet, if
we have  fallback that can use HTTP/1.1 or HTTP/2(if I am not wrong it
sounded as if it going in this diraction) the server side may deploy just
one version. The clients will be in the same situation as with WebSockets.
... we can also say this is a new thing and it should be deploy on a
separate origin for easier configuration.

dragana


> We only have a problem if, for a given :protocol, the client and server
> might disagree about whether it is defined for a given HTTP version.  If a
> disagreement occurs, it's our fault, for changing our minds about what is
> allowed where.
>
>   Those protocols might get a fresh definition for the new HTTP version,
>> but I don't think we can guarantee that they will all have definitions at
>> the time you might first deploy that new HTTP version.
>>
>
> I don't see why we can't guarantee that.
>