When using mod_wsgi daemon mode and a POST request is received, with the amount of content 
being greater in size than the UNIX socket buffer size for the host being used, and the 
application doesn't consume the request content before sending a response, and the response 
headers plus response content is itself greater than the UNIX socket buffer size, then a deadlock 
can occur.

This is because the Apache child process side is still trying to write the request content and is 
therefore not in a position to read the response headers and response content and unblock the 
daemon side trying to write the response.

For the typical well behaved application this doesn't present a problem. The sort of use case 
where it would occur is where specifically doing things like streaming back the request content 
as the response content, possibly with modifications. Only actual situation where a problem has 
been seen in practice is where SPAM bots are performing POST requests with large amounts of 
content against arbitrary URLs. Thus, the SPAM bots are inadvertently triggering the problem and 
not normal application usage.

The actual deadlock is not permanent and will end when the timeout specified by the Apache 
Timeout directive has elapsed, typically 300 seconds.

Note that how severe the problem is is dictated by size of UNIX socket buffers. On some UNIX 
systems this is as low as 8KB (MacOS X). On Linux systems it is a lot higher. In mod_wsgi 2.0c5 
an option will exist for WSGIDaemonProcess to allow the send and recv buffer sizes for the UNIX 
socket to be increased so where a system has a default low value, it can be increased and lesson 
risk of problem occurring.

To totally eliminate this issue means reengineering the protocol used between Apache child 
process and daemon process with a packet based mechanism in conjunction with flow control 
mechanisms so that daemon can indicate when it is willing to accept more request content. How 
this may be done has been discussed extensively on the mod_wsgi mailing list.

BTW, this deadlock issue also exists with mod_cgi, mod_cgid and mod_scgi, as these all use a 
similar system based around a UNIX socket or interprocess pipe. Conceptually a deadlock 
situation may be triggered with mod_proxy as well, but in that case INET sockets are used and 
the buffer sizes on these are much much larger. Still need to determine what the critical size 
values for mod_proxy to cause a deadlock is, if it also can suffer this problem. It is possible for 
mod_proxy that some other magic happens in Apache to prevent it, but haven't been able to 
determine what that is as yet if it does exist.