Subject: [quicwg/base-drafts] [HTTP/3] [editorial] 421 and future connection reuse. (#3218)

From: Bence Béky <[email-masked]>
Date: Mon, 11 Nov 2019 12:32:23 -0800

Status code 421 does not indicate to clients that the connection should
not be reused for subsequent requests for a particular origin.  It only
indicates that the server is not able to produce a reponse to one
particular request.  See
https://httpwg.org/specs/rfc7540.html#MisdirectedRequest.

In case it is desirable that clients do not reuse the connection for
subsequent requests for a particular origin, that it a deviation from
the original description of 421 and should be called out explicitly.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3218

-- Commit Summary --

  * [HTTP/3] [editorial] 421 and future connection reuse.

-- File Changes --

    M draft-ietf-quic-http.md (7)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3218.patch
https://github.com/quicwg/base-drafts/pull/3218.diff

-- 
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/pull/3218

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Nov 2019 12:50:44 -0800

>From 7540, as you quote, emphasis added:
> The 421 (Misdirected Request) status code indicates that the request was directed at a server that is not able to produce a response. **This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.**

It's true that the definition of 421 doesn't call out client behavior for future requests, but the condition it describes would apply to an entire origin, so that's a logical implementation (and what I believe most user-agents do).

Is your suggestion that we not explicitly call out that behavior, or make it only illustrative?

>From RFC7838:
>    Clients receiving 421 (Misdirected Request) from an alternative service MUST remove the corresponding entry from its alternative service cache (see Section 2.2) for that origin.

Dealing specifically with alternatives, this requirement has the direct effect that you don't ask the alternate for any other resources from that origin, even though you still have a connection open to it.  In the current state of the draft, this has the effect of disabling HTTP/3 for that origin until you get a fresh Alt-Svc entry.

-- 
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/pull/3218#issuecomment-552609859

---

From: Bence Béky <[email-masked]>
Date: Tue, 12 Nov 2019 04:51:37 -0800

Thanks for the response.  In light of your explanation I'm not sure I could improve the wording here, or that it would need to be improved in the first place.

-- 
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/pull/3218#issuecomment-552880177

---

From: Bence Béky <[email-masked]>
Date: Tue, 12 Nov 2019 04:51:38 -0800

Closed #3218.

-- 
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/pull/3218#event-2791342034

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Nov 2019 09:51:45 -0800

I suspect you're right that we need to retouch this language based on the language in http-core that will (we expect) permit trying HTTP/3 directly, without Alt-Svc.  That piece is tracked by #2223; mentioning it to make sure they're linked.

-- 
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/pull/3218#issuecomment-553011101