2 PCs with httpd-2.0.55 running and https enabled (OS SLES9). The first one is the "real" webserver with all the documents (HTML-pages, etc), the other webserver is configured as a reverse proxy which gets all the data from the "real" webserver. With a browser I can access both webservers and everything seems to be OK. The problem: When I get a form (method="post") through the reverse proxy and send it back, some of the "post"ed data dont reach the "real" webserver. It seems to happen always if the total amount of posted data is larger than 8 kbytes. When I get a form from the "real" webserver directly and send it back there is no loss of data (at any amount). The "real" webserver and the reverse proxy are talking via https to each other. Switching to http does not solve the problem. When _both_ webservers are switched to http the problem has disappeared, but this is not really a solution for me. Downgrading the reverse proxy to httpd-2.0.54 (both webservers with https, "real" webserver stays with httpd-2.0.55) solved the problem. During all tries I left the httpd.conf and ssl.conf unchanged (exception: ProxyPass and ProxyPassReverse for http/https switching of course) Reverse proxy configuration: <IfModule mod_proxy.c> SSLProxyEngine on ProxyRequests off ProxyPass / https://10.34.56.78/ ProxyPassReverse / https://10.34.56.78/ </IFModule>
Thanks for the report. Some questions: 1. Could you please attach an errorlog for a problematic POST request with LogLevel set to debug? 2. You say that some of the data posted gets lost when the posted data is larger than 8k. Can you specify how much data gets lost (e.g. Does everything beyond the first 8k get lost or are only the last 8k missing or something else)?
Please enable also mod_dumpio on the reverse proxy, set DumpIOInput On in your configuration and attach the output for a faulty POST request (contained in errorlog file).
After a short discussion on IRC with William A. Rowe, Jr. (a.k.a. wrowe, OtherBill), he additionally proposed to add the following patch to your reverse proxy and check if the problem is gone then: http://people.apache.org/~wrowe/httpd-2.0-proto-timeout.patch
As of now I guess you can wait with answering my questions / adding OtherBills patch. I already have an idea what the reason is and need to discuss this with the other developers on the dev list.
The patch was applied and didn't solve the problem. In a form with a lot of <input type="hidden" ..> lines only the _last_ approx. 8 kbytes reach the "real" webserver (visible by dumping the $_POST hash in the "action" PHP-script). All data posted before are lost. Using the form content <input type="file" ..> I can only upload files smaller than 7660 bytes. Otherwise I get an error-message of the "action"-script complaining about missing parameters.
Created attachment 16743 [details] Patch against 2.0.55 Could you please give the attached patch a try (on the reverse proxy)? I have not finished my discussion on possible sideeffects with other developers, so the patch might be subject to change. But it would be helpful to know if it fixes your problem.
Your attached patch solved the problem. :-) Thank you very much!
Created attachment 16744 [details] Fix 3 addtional occurences. Patch against 2.0.55 Can you please also test the following extended patch? Meanwhile I identified 3 others positions in the proxy code path which can cause this kind of trouble. Would be nice if you can give it a try too :-)
(In reply to comment #8) > Fix 3 addtional occurences. Patch against 2.0.55 This patch is working fine either. The reverse proxy performs perfectly. No loss of data anymore.
Thanks for the fast feedback.
(In reply to comment #10) > Thanks for the fast feedback. JFYI, this patch is also working fine with Outlook Web Access on IIS6 as proxied machine.
Meanwhile the patch was commited to trunk (r327590): http://svn.apache.org/viewcvs?rev=327590&view=rev To 2.2.x (r327592): http://svn.apache.org/viewcvs?rev=327592&view=rev and proposed for backport to 2.0.x: http://svn.apache.org/viewcvs?rev=327597&view=rev
*** Bug 37251 has been marked as a duplicate of this bug. ***
*** Bug 37421 has been marked as a duplicate of this bug. ***
*** Bug 37739 has been marked as a duplicate of this bug. ***
*** Bug 38141 has been marked as a duplicate of this bug. ***
Any timeframe on when 2.0.56 will be out with the patch in it? Lorinda
The patch has been backported to 2.0.x r372046 (http://svn.apache.org/viewcvs?rev=372046&view=rev) and will be part of 2.0.56. For the status of 2.0.56 please have a look at http://svn.apache.org/viewcvs.cgi/httpd/httpd/branches/2.0.x/STATUS?view=markup.
*** Bug 38837 has been marked as a duplicate of this bug. ***
*** Bug 38974 has been marked as a duplicate of this bug. ***
*** Bug 39274 has been marked as a duplicate of this bug. ***
*** Bug 38505 has been marked as a duplicate of this bug. ***
I am still seeing these errors on 2.0.58 & 2.2.2 using mod_proxy for a reverse proxy for RPC over HTTP and Exchange. Downgrading to 2.0.54 fixes the problem, maybe there are still some other occurences besides the ones patched here that have not been fixed? I also tried this on 2.2.2 and it didn't work either. [Tue Jun 27 18:08:08 2006] [error] (70014)End of file found: proxy: prefetch request body failed to 10.2.181.53 from 15.235.153.107 () [Tue Jun 27 19:07:46 2006] [error] (104)Connection reset by peer: proxy: prefetch request body failed to 10.2.181.53 from 10.2.181.18 ()
Sorry, but currently I do not see a relation to this bug. Your error messages indicate that the connection to the client broke during reading the POST request body. This bug is about POST request bodies passed to the backend server getting corrupted.