I think :protocol should be analogous to Content-Type. Whether a given :protocol value is supported should be a property of the resource, not the origin, and certainly not the server. Otherwise, it will be very difficult to roll out support for new :protocols. As an extreme example, consider a CDN that serves many origins in a single certificate (as is common). The backend servers for these different origins might have wildly different sets of supported :protocols, but they will all share a single HTTP/2 connection to the client. There is no SETTINGS value that the CDN could send to explain which :protocols are supported, as it depends on the origin of each request. Similar considerations apply for a single origin that offers distinct services at different paths. In my view, the problem here is WebTransport's use of :protocol. I think this use is very special and weird: it is a request header on a single request that modifies the entire connection. This breaks the whole HTTP layering model. I would prefer to spell this some other way (e.g. add "multistream representations" to HTTP), but failing that, I think we should understand that WebTransport is Super Weird and its use of :protocol is the least of it.
Received on Tuesday, 2 November 2021 14:10:43 UTC