Ticket #622 (defect)

The following applies to wsgiserver, rev [1534].

In some cases, a client will send a request body that is never read, or never read fully. This can occur when the request entity is too large (and 413 is returned), and also when InternalRedirect is raised before the request body is read. In both cases, the server will write a response to the socket. What happens next depends on whether the server then chooses to close the connection or not:

• When the connection is closed, there are rare cases where the client will not be able to read the server response from the socket before the socket is closed. When this happens, the user will not see the response, and will usually only see an error on the socket.read call. Due to the nature of TCP, there's really no way for the client to distinguish between this situation and the case of the server simply not responding.
• When the connection is not closed, the next attempt to read a request from the stream will error, since the first line in the previous, lingering request body is probably not a valid Request-Line (but if it is, this may be an exploitable hole that needs further investigation). When this happens, the server will close the connection.

Apache had this same problem and addressed it with the ap_lingering_close function. Given that solution's long and interesting history, and the rarity of the problem, I'm not sure we need to rush a fix for this. But be aware there's at least one test case in our current suite which can run into this (the early_ir call inside test_core).