Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into from
Closed

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

wants to merge 1 commit into from

Conversation

bencebeky
Copy link
Contributor

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.

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.
@MikeBishop
Copy link
Contributor

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.

@bencebeky
Copy link
Contributor Author

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.

@bencebeky bencebeky closed this Nov 12, 2019
@bencebeky bencebeky deleted the bencebeky-http3-misdirected branch November 12, 2019 12:52
@MikeBishop
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants