The HTTP RFCs say nothing about the expectations around half-closed TCP connections.
In practice, I haven't seen any HTTP client in the wild send a request, and then send a FIN (shutdown) while still waiting for the server's response.
Because we haven't see any clients do that, as of Go 1.8, Go's HTTP server is starting to make assumptions that reading an EOF from the client means that the client is no longer interested in the response. (reading EOF being the closest portable approximation to "the client has gone away").
But in golang/go#18527, a user reports that they have an internal HTTP client which does indeed make a half-closed TCP request.
It would be nice if the HTTP RFCs provided guidance as to whether this is allowed or frowned upon.
I would recommend that the RFC suggest that clients SHOULD NOT half-close their TCP connections while awaiting responses. Because nobody else does, empirically, and relying on reading EOF is a useful signal for servers.
/cc @mnot @benburkert
The HTTP RFCs say nothing about the expectations around half-closed TCP connections.
In practice, I haven't seen any HTTP client in the wild send a request, and then send a FIN (
shutdown) while still waiting for the server's response.Because we haven't see any clients do that, as of Go 1.8, Go's HTTP server is starting to make assumptions that reading an EOF from the client means that the client is no longer interested in the response. (reading EOF being the closest portable approximation to "the client has gone away").
But in golang/go#18527, a user reports that they have an internal HTTP client which does indeed make a half-closed TCP request.
It would be nice if the HTTP RFCs provided guidance as to whether this is allowed or frowned upon.
I would recommend that the RFC suggest that clients SHOULD NOT half-close their TCP connections while awaiting responses. Because nobody else does, empirically, and relying on reading EOF is a useful signal for servers.
/cc @mnot @benburkert