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

Handle HTTP/2 half-closed connections gracefully #775

Open
karpetrosyan opened this issue Aug 9, 2023 · 1 comment · May be fixed by #777
Open

Handle HTTP/2 half-closed connections gracefully #775

karpetrosyan opened this issue Aug 9, 2023 · 1 comment · May be fixed by #777

Comments

@karpetrosyan
Copy link
Member

Discussion: #750
Refs: #641

This is the same as #723 but for http/2 connections

@tomchristie
Copy link
Member

So the equivalent for HTTP/2 here is this...

https://httpwg.org/specs/rfc7540.html#HttpSequence

An HTTP response is complete after the server sends — or the client receives — a frame with the END_STREAM flag set (including any CONTINUATION frames needed to complete a header block). A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag). Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons.

We haven't had any users observe or request this so we don't need to treat it as high priority. Starting out with a test case for this sequence of frames would be the way to go. I'm not sure what our behaviour currently is here.

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