You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Kalyana sundaram <ka...@gmail.com> on 2014/01/20 11:31:14 UTC
[users@httpd] Issue with LimitRequestBody
Hi
I am using httpd-2.2.26. Whenever I use LimitRequestBody directive Apache
gives 413 to user if content length is greater than the value specified in
directive but logs as 200. It even appends the response html along with
error document. This problem happens in httpd-2.4.4 also
On further debugging 2.2.26 with gdb i found the problem occurs in
modules/http/http_request.c (ap_process_request) line 291
if (access_status == OK) {
ap_finalize_request_protocol(r);
}
else {
r->status = HTTP_OK;
ap_die(access_status, r);
}
the access_status for request which are to reponsed to 413 is not OK(it is
-3). So it reaches else part, which sets status as 200 and calls ap_die
If I make the change as
if (access_status == OK||r->status==413) {
ap_finalize_request_protocol(r);
}
else {
r->status = HTTP_OK;
ap_die(access_status, r);
}
It works fine, I know this is small hack to hide the issue. Is there a open
bug in httpd for this?
Does this change causes any performance issue/ failures?
Let me know is there a cleaner way to enforce LimitRequestBody
--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/
Re: [users@httpd] Issue with LimitRequestBody
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 20, 2014 at 8:25 AM, Kalyana sundaram <ka...@gmail.com> wrote:
> access_status is -3 and r->status is 413. But I am not getting why in
> ap_process_request r->status is set to HTTP_OK before calling ap_die. This
> seems like causing the issue
>
-3 is AP_FILTER_ERROR (in 2.2.x). That makes sense for the limit
request body trigger which happens in a filter.
That single line is the entirety of what was changed for this
recursive errordoc issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=36090
Maybe this patch was incomplete or did as much harm as good where a
more elaborate fix to ap_die was needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Issue with LimitRequestBody
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 20, 2014 at 8:25 AM, Kalyana sundaram <ka...@gmail.com> wrote:
> access_status is -3 and r->status is 413. But I am not getting why in
> ap_process_request r->status is set to HTTP_OK before calling ap_die. This
> seems like causing the issue
>
-3 is AP_FILTER_ERROR (in 2.2.x). That makes sense for the limit
request body trigger which happens in a filter.
That single line is the entirety of what was changed for this
recursive errordoc issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=36090
Maybe this patch was incomplete or did as much harm as good where a
more elaborate fix to ap_die was needed.
Re: [users@httpd] Issue with LimitRequestBody
Posted by Kalyana sundaram <ka...@gmail.com>.
access_status is -3 and r->status is 413. But I am not getting why in
ap_process_request r->status is set to HTTP_OK before calling ap_die. This
seems like causing the issue
On Mon, Jan 20, 2014 at 6:49 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 8:13 AM, Kalyana sundaram <ka...@gmail.com>
> wrote:
> > If ap_die is called
> > 413 is the response code on header sent to client
> > 200 is the response code on logs
> > body has the error document and the response appended
> >
> > If ap_finalize_request_protocol is called
> > 413 is response code on header
> > 413 is logged
> > response is not appended to error document
>
> I don't think Apache can just chuck the response when the handler did
> not return an error (the "access_status" return value) vs. succesfully
> generating a non-200 response (returning OK with r->status set to 413
> during the course of execution). I think the error document has been
> queued up under the assumption that whoever sees that request-reading
> error will surely return an error.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/
Re: [users@httpd] Issue with LimitRequestBody
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 20, 2014 at 8:13 AM, Kalyana sundaram <ka...@gmail.com> wrote:
> If ap_die is called
> 413 is the response code on header sent to client
> 200 is the response code on logs
> body has the error document and the response appended
>
> If ap_finalize_request_protocol is called
> 413 is response code on header
> 413 is logged
> response is not appended to error document
I don't think Apache can just chuck the response when the handler did
not return an error (the "access_status" return value) vs. succesfully
generating a non-200 response (returning OK with r->status set to 413
during the course of execution). I think the error document has been
queued up under the assumption that whoever sees that request-reading
error will surely return an error.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Issue with LimitRequestBody
Posted by Kalyana sundaram <ka...@gmail.com>.
If ap_die is called
413 is the response code on header sent to client
200 is the response code on logs
body has the error document and the response appended
If ap_finalize_request_protocol is called
413 is response code on header
413 is logged
response is not appended to error document
On Mon, Jan 20, 2014 at 6:36 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 7:29 AM, Kalyana sundaram <ka...@gmail.com>
> wrote:
> > But if I call ap_finalize_request_protocol(r) instead of using else
> part,
> > things are fine
> > Thats why I wish to understand, when mod_php is called
>
> Ignoring all of the cases you aren't testing, what's the behavior in
> that case (headers & body & log entry?).
>
> Was the output generated by your script used in the response or discarded?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/
Re: [users@httpd] Issue with LimitRequestBody
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 20, 2014 at 7:29 AM, Kalyana sundaram <ka...@gmail.com> wrote:
> But if I call ap_finalize_request_protocol(r) instead of using else part,
> things are fine
> Thats why I wish to understand, when mod_php is called
Ignoring all of the cases you aren't testing, what's the behavior in
that case (headers & body & log entry?).
Was the output generated by your script used in the response or discarded?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Issue with LimitRequestBody
Posted by Kalyana sundaram <ka...@gmail.com>.
But if I call ap_finalize_request_protocol(r) instead of using else part,
things are fine
Thats why I wish to understand, when mod_php is called
On Mon, Jan 20, 2014 at 5:51 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 7:11 AM, Kalyana sundaram <ka...@gmail.com>
> wrote:
> > <html>===>php response
>
> As I had described, whatever you're using for PHP (probably mod_php)
> is ignoring errors while reading the request body and allowing your
> script to run and append output. I suggest you search for / report a
> bug to the PHP project.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/
Re: [users@httpd] Issue with LimitRequestBody
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 20, 2014 at 7:11 AM, Kalyana sundaram <ka...@gmail.com> wrote:
> <html>===>php response
As I had described, whatever you're using for PHP (probably mod_php)
is ignoring errors while reading the request body and allowing your
script to run and append output. I suggest you search for / report a
bug to the PHP project.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Issue with LimitRequestBody
Posted by Kalyana sundaram <ka...@gmail.com>.
On Mon, Jan 20, 2014 at 5:21 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 5:31 AM, Kalyana sundaram <ka...@gmail.com>
> wrote:
> >
> > Hi
> > I am using httpd-2.2.26. Whenever I use LimitRequestBody directive Apache
> > gives 413 to user if content length is greater than the value specified
> in
> > directive but logs as 200. It even appends the response html along with
> > error document. This problem happens in httpd-2.4.4 also
> > On further debugging 2.2.26 with gdb i found the problem occurs in
> > modules/http/http_request.c (ap_process_request) line 291
> >
> > if (access_status == OK) {
> > ap_finalize_request_protocol(r);
> > }
> > else {
> > r->status = HTTP_OK;
> > ap_die(access_status, r);
> > }
>
> What module are you using to write the response? ap_die copies the
> first paraemter to r->status so you shouldn't need something special.
>
> But it doesnt happen like that. the client receives 413 but also the
response is appended to the error document
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/index.php<br />
does not allow request data with POST requests, or the amount of data
provided in
the request exceeds the capacity limit.
<hr>
<address>Apache/2.2.22 (Ubuntu) Server at localhost Port 8080</address>
</body></html>
<html>===>php response
HOME
</html>
The response is logged as 200. Could you try it out on a vhost and do a
simple curl to see it
> A 413 triggers an error reading the request body. If you ignore it,
> things go wrong. If you return the error you receive, it works.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/
Re: [users@httpd] Issue with LimitRequestBody
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 20, 2014 at 5:31 AM, Kalyana sundaram <ka...@gmail.com> wrote:
>
> Hi
> I am using httpd-2.2.26. Whenever I use LimitRequestBody directive Apache
> gives 413 to user if content length is greater than the value specified in
> directive but logs as 200. It even appends the response html along with
> error document. This problem happens in httpd-2.4.4 also
> On further debugging 2.2.26 with gdb i found the problem occurs in
> modules/http/http_request.c (ap_process_request) line 291
>
> if (access_status == OK) {
> ap_finalize_request_protocol(r);
> }
> else {
> r->status = HTTP_OK;
> ap_die(access_status, r);
> }
What module are you using to write the response? ap_die copies the
first paraemter to r->status so you shouldn't need something special.
A 413 triggers an error reading the request body. If you ignore it,
things go wrong. If you return the error you receive, it works.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org