-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
It's completely valid for a client to send a TCP FIN upon finishing sending an one-off request, the server should still process things and send the response.
However, after #3665 , we put the dispatcher in shutdown state after detecting that the client closed its writer side of the connection. After being in shutdown state, the server will only try to flush its local writer buffer and shutdown, which means that it won't call poll_response
anymore, and thus won't give opportunity for the user code to keep sending the response data.
#3665 Can indeed "solve" part of #1313 , by the fact that we now consider a FIN from the client as a complete connection shutdown, but that isn't a correct assumption from the TCP standpoint. I think some of the examples in #1313 was causing problems due to #3747 , but probably not all.
I think we should revert #3665 , that would mean that user handlers that don't try to send or receive anything will get back to hanging until they try to read/write something. We will either need to find another solution for that or declare that such handlers are problematic, but we probably should open a new issue, since the #1313 is already a mess of different examples.