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_notifywhen the client has nothing to send.This is motivated by server H2 implementations sending
go_awayframes and then closing the connections without aclose_notifyin 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.