DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21035>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21035 Apache 1.3.27 problem using ErrorDocument with LimitRequestBody directive Summary: Apache 1.3.27 problem using ErrorDocument with LimitRequestBody directive Product: Apache httpd-1.3 Version: 1.3.27 Platform: HP OS/Version: HP-UX Status: NEW Severity: Normal Priority: Other Component: Other AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] If LimitRequestBody directive is set for a apache web server with user defined ErrorDocument configured (for 413 error) and a client sends request exceeding the value set in LimitRequestBody then apache does not display the user defined ErrorDocument. It instead displays the standard 413 error document. This happens only for local redirects(/xyz.htm) while external redirects (http://hostname/xyz.htm) work fine. Steps to reproduce the problem, 1. Configure the httpd.conf to use LimitRequestBody directive by adding, LimitRequestBody 2000 2. Add a customized error response for the error from above directive. ErrorDocument 413 /e413.htm 3. Make a request from the client with content length greater than 2000. This should result in a error with the customized error html e413.htm but instead it displays the standard 413 error message. It looks like the problem is because apache keeps the content-lenght of the original request even for the local redirect. So, in the process of displaying error document, it again hits the request body limit and throws the standard 413 error. I could get it to work by unsetting the "Content-Length" but I am not sure if this is the correct fix and if there is any impact of this on any other apache functionality. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
