You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Bill Bishop <b...@bandkshow.com> on 2004/08/28 01:05:20 UTC
[users@httpd] LimitRequestSize and ErrorDocument problem with recursion due to socket flush failure
If the following directive:
LimitRequestSize 102400
is used in the context of a VirtualHost or Directory, or anywhere else as
far as I can tell, the result of exceeding the limit in a PUT or POST is an
HTTP-413, which is the value returned when the test fails in
http_protocol.c:ap_setup_client_block(). (The macro for this value is
HTTP_REQUEST_ENTITY_TOO_LARGE, defined in httpd.h.)
This works fine, until the ErrorDocument directive is used as follows:
ErrorDocument 413 /some/path/to/a/document.html
This fails because the call in ap_die() to ap_discard_request_body() calls
ap_setup_client_block() again, and it fails again because the body is still
too long. As a result, another line is appended to the error message, but
the custom error page is not displayed.
This problem appears specific to the 413 status; it could also happen if the
request is of a type that causes the call to ap_setup_client_block(), which
is a standard module call, not to allow a body at all (which will produce
the same 413), but it appears that ap_discard_request_body() calls
ap_setup_client_block() with REQUEST_CHUNKED_PASS, so this cannot happen for
that condition; only exceeding LimitRequestSize can do this. In other words,
if the request type does not allow a body, and a body is present, then the
ErrorDocument will be used; only if LimitRequestSize is exceeded will the
ErrorDocument not be used.
I believe that this could be fixed by modifying ap_setup_client_block()to
check r->status (r is a request_rec, and status is the member that holds the
HTTP status code) and not run the check if it is 413. This looks like it
would be OK because ap_read_request() initializes it to HTTP_OK (200, in
httpd.h) during the request read phase. Does anyone see anything wrong with
this that could create a hole?
The other alternative is to make a new routine that does all the things that
ap_setup_client_block() does except the LimitRequestSize check, and call
that from ap_discard_request_body(). I don't think this is necessary.
Feedback please.
-B^2
;)
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] LimitRequestSize and ErrorDocument problem with recursion due to socket flush failure
Posted by Bill Bishop <b...@bandkshow.com>.
This code exists in 1.3.29, 1.3.30, and the current 1.3.31. I have not
examined the code in any 2.x version, and do not intend at this time to
switch, since I have several other dependencies that will need to be
addressed in the switch to 2.x. I need to fix this problem for the most
current 1.3.x release; I will check the code in 2.x for this problem when I
begin preparing for the switch to whatever release is most current in that
codeline.
-B^2
;)
> -----Original Message-----
> From: Nick Kew [mailto:nick@webthing.com]
> Sent: Friday, August 27, 2004 5:17 PM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] LimitRequestSize and ErrorDocument problem with
> recursion due to socket flush failure
>
> On Fri, 27 Aug 2004, Bill Bishop wrote:
>
> > If the following directive:
> >
> > LimitRequestSize 102400
> >
> > is used in the context of a VirtualHost or Directory, or anywhere else
> as
> > far as I can tell, the result of exceeding the limit in a PUT or POST is
> an
> > HTTP-413, which is the value returned when the test fails in
> > http_protocol.c:ap_setup_client_block(). (The macro for this value is
> > HTTP_REQUEST_ENTITY_TOO_LARGE, defined in httpd.h.)
>
> This sounds like an old version of Apache. AFAICS ap_discard_request_body
> doesn't use the deprecated ap_setup_client_block API. Do you get such a
> problem with an up-to-date Apache?
>
> --
> Nick Kew
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] LimitRequestSize and ErrorDocument problem with
recursion due to socket flush failure
Posted by Nick Kew <ni...@webthing.com>.
On Fri, 27 Aug 2004, Bill Bishop wrote:
> If the following directive:
>
> LimitRequestSize 102400
>
> is used in the context of a VirtualHost or Directory, or anywhere else as
> far as I can tell, the result of exceeding the limit in a PUT or POST is an
> HTTP-413, which is the value returned when the test fails in
> http_protocol.c:ap_setup_client_block(). (The macro for this value is
> HTTP_REQUEST_ENTITY_TOO_LARGE, defined in httpd.h.)
This sounds like an old version of Apache. AFAICS ap_discard_request_body
doesn't use the deprecated ap_setup_client_block API. Do you get such a
problem with an up-to-date Apache?
--
Nick Kew
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org