-
-
Notifications
You must be signed in to change notification settings - Fork 305
feat: not return UnexpectedEof when server drops without close_notify #847
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
feat: not return UnexpectedEof when server drops without close_notify #847
Conversation
Example logs:
|
This probably makes sense (at least, nothing wrong comes immediately to mind!). Looks like CI didn't like a thing 🤓 |
5a3477a
to
bbae3d3
Compare
bbae3d3
to
76ee7bb
Compare
CI issues addressed 👍 |
Just looked at this again, and I think this is mostly right. One concern I thought of: if we got this error not from a TLS shutdown, but just from a server process that crashes suddenly without a GOAWAY frame even, shouldn't we report that error to the client? |
I added a change so that in clients the EoF is propogated unless the server has sent a If I don't include the |
This PR extends the change made in #743 to include client connections that are closed by servers that drop connections without sending
close_notify
when the client has nothing to send.This is motivated by server H2 implementations sending
go_away
frames and then closing the connections without aclose_notify
in longer lived applications (specifically DoH).I originally reported this as an issue in the
hickory-dns
(hickory-dns/hickory-dns#3064) but after discussion with @djc the real underlying issue seems to be the handling of this type of intentional connections close within the H2 client.