Situation: Client requests JSP page to local apache server (2.0.47). Local apache server forwards mod_proxy) this request to a central apache server (2.0.47) which is connected by mod_jk2 (2.0.2) to tomcat 4.1.24. When the local apache server receives its response, the request-response status line is malformed and a warning is generated in the apache error log file. The JSP application works fine, but our log files are clogged with these warnings as every JSP request generates one. We are talking about a major enterprise-wide global system. Examining this problem showed that the error is caused by the fact that mod_proxy is cleaning up/ignoring the trailing space in the status line:"HTTP/1.1 200 ". It only seems to see or evaluate "HTTP/1.1 200". I read that mod_jk omits the reponse-phrase ("OK" in this case) but this should (according to standards) not be a problem when at least a trailing space is added. By tracing the connactions I can see the 'space' in the response status line before it enters apache. Either mod_proxy filters out the space or the incoming status line is incorrectly evaluated. The error message is generated in httpd-2.0.47/modules/proxy/proxy_http.c line 761 For more information, please check http://article.gmane.org/gmane.comp.apache.mod-proxy/561
Thanks for the report. Yes, ap_rgetline is stripping any trailing spaces. The proxy should just fix it and not be so noisy - I'll attach a patch.
Created attachment 8666 [details] fix for trailing space handling
I tested the fix that was supplied and everything works OK. I attached two error log files - one showing the warning, and one which shows the warning is gone. Both error log files were recorded while requesting the default application jsp in out environment, with the apache mod_proxy instance running in debug mode.
Created attachment 8690 [details] Apache error log file, including 'warning' bug
Created attachment 8691 [details] Apache error log file, bug fixed using supplied patch (no more warning)
fyi... fix already in 2.1-dev, recently approved for merge into stable branch for 2.0.next
As Jeff already noted, this is fixed.