- From: Dragana Damjanovic <dragana.damjano@gmail.com>
- Date: Wed, 20 Oct 2021 21:14:18 +0200
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Ben Schwartz <bemasc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAG0m4gTArto800bOUwsQEHYHLdh6vv6i5iHvEt6=cVNn0ZkQ2g@mail.gmail.com>
On Wed, Oct 20, 2021 at 9:03 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > > On Wed, Oct 20, 2021 at 6:27 PM Ben Schwartz <bemasc@google.com> wrote: > >> >> >> 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. >> > > Again I don't know how you can make these two things align. There's a > difference between "my origin supports retrieving a resource using HTTP" > and a client and server actually selecting the HTTP version to use for > that. This is even more true when intermediaries are in the mix, because > the page that includes a URL could be very far removed from the (multi) CDN > that is responsible for the details of the connection that is formed > between it and a client. We purposefully avoided encoding the HTTP version > in the scheme, but it kind of all works ok due to Alt-Svc. > > With WebSocket, the origin could support only WebSocket via HTTP/1.1 > upgrade. An intermediary could support WebSocket over some of HTTP/1.1, > HTTP/2 or HTTP/3; converting to what the origin uses on the backend. It's > very hard for an origin to react to permutations of these setups, > especially across different providers. Just hoping everyone enables all > forms of support doesn't seem realistic to me. > > I agree with this point. I think my messages was sent at the almost same time as this. I have open an issue at w3c about adding hint when opening WebSockets as well, but I am not sure that would salve all the problems: https://github.com/whatwg/html/issues/7243 > Tangent: > > How to respond to a client when SETTINGS_ENABLE_CONNECT_PROTOCOL is > enabled but a value of ":protocol" is not supported is IMO actually pretty > poorly defined in RFC 8441. And draft-ietf-masque-connect-udp doesn't > really say much either. If a server sends 404, it could imply the web > socket resource doesn't exist at all. That's not true, it exists but can > only be accessed using a specific HTTP version. > > This is a very good point I think we need more specific SETTINGS_ENABLE_CONNECT_PROTOCOL or a new response code somewhat similar to 421 (but it is not the same). dragana Cheers > Lucas >
Received on Wednesday, 20 October 2021 19:15:42 UTC