Re: Advertising WebSocket support in the HTTPS resource record

On Fri, Oct 22, 2021, at 13:07, Ben Schwartz wrote:
> I see deep implications here.

Same.

> If an origin advertises HTTP/3 support, it is saying "this origin is 
> compatible with HTTP/3-only clients".  HTTP/3 clients are not required 
> to implement HTTP/2 or HTTP/1.1.

I don't think that that is quite right.  You might *like* that to be the case, but it is not how things work.

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.

This pattern will continue as long as we continue to invent "X over HTTP" with weird interaction methods (think WebTransport and MASQUE).  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.

This attitude effectively means these special "X over HTTP" protocols always need to be deployed on a different domain name.  The upgrade cycle of HTTP would not affect them.

This idea that we might want to avoid HTTP-version downgrade for these adjunct protocols is fine in theory, but I think that it's not doing us any favours.

I don't disagree with your other conclusions; I find the idea that you might need to say "please use HTTP/X for this combination of resource and feature" is quite horrifying.  I also don't have a concrete proposal for how to deal with it.  I'm interested in hearing what people come up with.

Received on Friday, 22 October 2021 06:55:27 UTC