Subject: [quicwg/base-drafts] Consider a specific error when switching to an HTTP/3 connection that does not support an extension (#3833)

From: Lucas Pardue <[email-masked]>
Date: Tue, 07 Jul 2020 16:29:07 -0700

I was reminded of an observation about Alt-Svc and Extensions that I made back in Oct '19 and posted to the HTTP WG https://lists.w3.org/Archives/Public/ietf-http-wg/2019OctDec/0022.html

To summarise the post:

RFC7838 defines the status code 421 Misdirected Request which can be used in some failure cases.

Now imagine: an HTTP/2 server supports WebSocket (RFC 8441) negotiated via SETTINGS_ENABLE_CONNECT. It advertises HTTP/3 using Alt-Svc, a client that switches over to HTTP/3 only to find that WebSockets are not supported in that version. The client may well decide to abort the connection at this point and fallback to H2. Having a specific error code to signal this case (similar in spirit to Status 421) could help endpoints discover this type of error.

This problem is not unique to WebSockets, there may be other extension scenarios that could affect switching between H2->H3, H3->H2, H2->H2, and H3->H3.

We might benefit from defining a specific error code as part of HTTP/3 from the get-go. However, given the chance of error in HTTP/2 this could be something that suits just creating an extension document to cover both versions. I'm open to either option so creating this issue to get better visibility and input.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Jul 2020 17:38:10 -0700

Generally speaking I would prefer each extension defining a SETTINGS parameter to indicate its availability, so that endpoints would not burn a round-trip testing if a feature is available on an established connection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#issuecomment-655211768

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 07 Jul 2020 18:20:11 -0700

I'm not sure I follow, sorry.

In my contrived example, the extension is negotiated via a SETTINGS parameter but it requires the client to burn an HTTP/3 handshake to learn that the HTTP/3 version of the same server instance does not implement the extension. At that stage there are a few options, one would be to send CONNECTION_CLOSE with error code H3_DESIRED_EXTENSION_UNSUPPORTED, one would be to migrate the vanilla HTTP requests to the H3 connection and maintain H2 only for the websocket. I think leaving most of that up to the implementation is fine, but having an error code could allow a server to discriminate this type of client problem from others.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#issuecomment-655223549

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 09 Jul 2020 07:56:04 -0700

As an individual, I believe that choosing to do address the issue would require a design change. 

However, I'm not labelling as such until there is any indication from the group that they believe this needs to be addressed in QUICv1.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#issuecomment-656177091

---

From: Mike Bishop <[email-masked]>
Date: Thu, 09 Jul 2020 13:07:54 -0700

This basically boils down to discovery that the indicated alternative is not, in fact, equivalent in some way that the client cares about.  That might be different extensions, different security parameters, even location in a different political jurisdiction.  (If you send me an alternative that turns out to be in China or Russia, I might not opt to use that one.)  I'm sure there are other ways for an alternative to be unacceptable that we haven't thought of.

I'm not sure it's profitable to go specify distinct error codes for them.  Clients just bounce back to origin if it finds the alternative unacceptable.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#issuecomment-656325857

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 09 Jul 2020 13:19:35 -0700

Yeah, my first primary motivation was to catch misconfigurations or synchronisation issues across the same fleet (maybe even cross-CDN or cross-cloud).

The h2->h3 path is only one manifestation. And as you rightly describe, this issue has a slew of broader considerations. For that reason, I think this needs to actually be its own draft which some other group of people can worry about. 

Furthermore, there is fundamentally nothing in the H3 protocol that makes the situation any worse than it than it already is. 

Let's just close this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#issuecomment-656331410

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 13 Jul 2020 05:33:51 -0700

While I had the context paged in, I wrote up https://datatracker.ietf.org/doc/draft-pardue-alt-svc-ext-unsupported/. Closing this issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#issuecomment-657533885

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 13 Jul 2020 05:33:53 -0700

Closed #3833.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3833#event-3539300046