I have more information on this apparent bug.
As I watch the requests move around, I noticed that when making the request through Squid, the connection: keep-alive and other relevant headers are set correctly. When making the request through mod_proxy, those headers disappear.
So, here is my take on this. I got mod_proxy to at least stop hanging and constantly hitting the origin server by adding the following two lines of code to mod_proxy.c:
origin->keep_alive = 0; apr_table_set( r->headers_in, "Connection", "Close );
This was done in the middle of the ap_proxy_http_request function in proxy_http.c.
This is, of course, not the right thing to do, but I wanted to see if it would fix the problem, and it did. I can now correctly proxy, even if it is slow because of the lack of keep-alive. I believe what is happening is mod_proxy_http is deciding to keep the connection alive on the backend, which is correct, but it is failing to inform the browser that it has done so. In the absence of information about keep-alive, the browser does not make any more requests on that socket, but also fails to open more of them, since it has a limit as to how many it can open, and the socket is not yet closed.
I am no expert on the nuances of when to send keep-alive headers and when not to, but it is clear that something is missing here.
I hope this helps. Please let me know if more details are needed.
C
In my browser, I set the proxy to be myproxy.mydomain.mytld at port 8008. Things seem to work all right for simple requests. However, requesting a really messy page like "www.cnn.com" causes some interesting problems. (For bug duplication purposes, I am currently using Mozilla 1.3a, but this has been duplicated on various versions of IE, as well).
After making the request to www.cnn.com, Apache must be forcefully restarted in order serve any other requests reliably. Request threads do not appear to want to give up their connection to the internet once the request is completed. An ethereal dump indicates that Apache is still sending TCP traffic to the destination server. An endless stream of ACK packets is sent to the destination server until Apache is forcefully restarted. I have verified that it is not the browser that is doing this.
