RE: Apache 1.3.x - Problem with handling ErrorDocument for 413 ?

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

Thanks for the consideration. I'll look forward for your feedback.

-Madhu

-Original Message-
From: Jim Jagielski [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 29, 2003 6:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Apache 1.3.x - Problem with handling ErrorDocument for 413
?



On Monday, June 23, 2003, at 10:32  AM, MATHIHALLI,MADHUSUDAN 
(HP-Cupertino,ex1) wrote:

 It'll be nice if somebody can please review the patch and give me the
 feedback..



I think that the below should wait until after 1.3.28.

RE: Apache 1.3.x - Problem with handling ErrorDocument for 413 ?

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

It'll be nice if somebody can please review the patch and give me the
feedback..

Thanks
-Madhu

-Original Message-
From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]
Sent: Friday, June 20, 2003 12:02 PM
To: '[EMAIL PROTECTED]'
Subject: Apache 1.3.x - Problem with handling ErrorDocument for 413 ?


Hi,
One of my collegue ran into this problem using Apache 1.3.27 (works
fine in Apache 2.0.x), and attached is a brief description.

1. Configure the httpd.conf to use LimitRequestBody directive by adding, 
   LimitRequestBody 1000

2. Add a customized error response for the above directive.
   ErrorDocument 413 /error413.htm

3. Make a request from the client with content length greater than 1000 (I
tried using POST)

This should result in a error with the customized error html error413.htm
but instead, it displays the standard 413 error message !!. If we do the
following, things seem work fine..

--- http_request.c  Fri Jun 21 16:59:16 2002
+++ http_request.c.new  Fri Jun 20 11:57:12 2003
@@ -1128,6 +1128,7 @@
r-method = ap_pstrdup(r-pool, GET);
r-method_number = M_GET;
}
+ap_table_unset(r-headers_in, Content-Length);
 ap_internal_redirect(custom_response, r);
 return;
 }

It's probably just masking the problem and not the correct solution.
We tried to discard the body before the redirect, but it wouldn't work, as
the request gets bitten again because of the call to
ap_setup_client_block().

Has anybody seen this problem before .. or is it a user error ?

Thanks,
-Madhu