You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2014/01/20 13:44:50 UTC
[Bug 56035] New: Issue with LimitRequestBody
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Bug ID: 56035
Summary: Issue with LimitRequestBody
Product: Apache httpd-2
Version: 2.2.26
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: bugs@httpd.apache.org
Reporter: kalyanceg@gmail.com
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
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #16 from Yann Ylavic <yl...@gmail.com> ---
(In reply to Eric Covener from comment #15)
> Current rev of patch has a problem with access_status=AP_FILTER_ERROR,
> ap_die will copy it to r->status, so the caller cannot restore it. Left at
> a negative value, it's logged as -.
I don't see how, in the proposed patch, ap_die() can set r->status to anything
than a valid HTTP status (AP_FILTER_ERROR, AP_NOBODY_READ/WROTE or whatever).
When the given access_status is not a valid HTTP status (as per
ap_is_HTTP_VALID_RESPONSE, negative values included), either ap_die() does
nothing (response already sent), or it is forced to HTTP_INTERNAL_SERVER_ERROR
(and so will be r->status below).
Do you have a path for this to happen?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Eric Covener <co...@gmail.com> ---
The handler has ignored errors returned during reading the request body
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #15 from Eric Covener <co...@gmail.com> ---
Current rev of patch has a problem with access_status=AP_FILTER_ERROR, ap_die
will copy it to r->status, so the caller cannot restore it. Left at a negative
value, it's logged as -.
it does seem like AP_FILTER_ERROR should maybe be unique for non-http status.
It a) has written an error and b) should not really be mapped further.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #12 from Yann Ylavic <yl...@gmail.com> ---
(In reply to maapu from comment #11)
> @Yann
> But why do we need to call ap_die incase of ap_is_HTTP_VALID_RESPONSE
> returns false. Why cant we just call ap_finalize_request_protocol? Will it
> miss some cases?
ap_die() ensures the client will receive an error response in any case, should
an handler return a non-HTTP status without responding by itself (or calling a
filter), "Internal Server Error" will be used.
For the logging bug however, I think the proposed patch(es) don't do the right
thing, ap_process_request() should always set r->status to HTTP_OK before
calling ap_die(), or the latter may think it's a recursive error (while it is
never here).
So maybe the correct way to handle this is to check whether the status is still
HTTP_OK after ap_die(), in which case a response has already been sent to the
client before, and the original r->status is relevant (and to be restored).
This new patch follows.
Regarding the double response body, as Eric said, this comes from (mod_)php
just ignoring the error, no httpd's level patch can resolve this IMHO.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #2 from maapu <ka...@gmail.com> ---
why is it made invalid?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
maapu <ka...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #4 from Eric Covener <co...@gmail.com> ---
Can you duplicate with a non-php testcase?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #7 from Eric Covener <co...@gmail.com> ---
In both cases, you're bailing out at the bottom of the block below here, so
r->status is not restored as it is later in ap_die:
AP_DECLARE(void) ap_die(int type, request_rec *r)
{
int error_index = ap_index_of_response(type);
char *custom_response = ap_response_code_string(r, error_index);
int recursive_error = 0;
request_rec *r_1st_err = r;
if (type == AP_FILTER_ERROR) {
ap_filter_t *next;
/*
* Check if we still have the ap_http_header_filter in place. If
* this is the case we should not ignore AP_FILTER_ERROR here because
* it means that we have not sent any response at all and never
* will. This is bad. Sent an internal server error instead.
*/
next = r->output_filters;
while (next && (next->frec != ap_http_header_filter_handle)) {
next = next->next;
}
/*
* If next != NULL then we left the while above because of
* next->frec == ap_http_header_filter
*/
if (next) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"Custom error page caused AP_FILTER_ERROR");
type = HTTP_INTERNAL_SERVER_ERROR;
}
else {
return;
}
}
It seems like it might be safer to avoid r->status = HTTP_OK in the caller if
the error is AP_FILTER_ERROR.
(I think the error in the other branch looks wrong too, it does not yet know
that that AP_FILTER_ERROR came from an errordoc creation / recursive call)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #9 from Yann Ylavic <yl...@gmail.com> ---
For ap_die() / ap_process[_async]_request() to handle any non-HTTP status
safer, maybe a more complete patch (against trunk) could be :
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1559728)
+++ modules/http/http_request.c (working copy)
@@ -75,12 +75,17 @@ static void update_r_in_filters(ap_filter_t *f,
AP_DECLARE(void) ap_die(int type, request_rec *r)
{
- int error_index = ap_index_of_response(type);
- char *custom_response = ap_response_code_string(r, error_index);
+ int error_index;
+ char *custom_response;
int recursive_error = 0;
request_rec *r_1st_err = r;
- if (type == AP_FILTER_ERROR) {
+ if (type == OK || type == DONE) {
+ ap_finalize_request_protocol(r);
+ return;
+ }
+
+ if (!ap_is_HTTP_VALID_RESPONSE(type)) {
ap_filter_t *next;
/*
@@ -99,8 +104,14 @@ AP_DECLARE(void) ap_die(int type, request_rec *r)
* next->frec == ap_http_header_filter
*/
if (next) {
- ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
- "Custom error page caused AP_FILTER_ERROR");
+ if (type == AP_FILTER_ERROR) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
+ "Custom error page caused AP_FILTER_ERROR");
+ }
+ else {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO()
+ "Invalid error response status %i", type);
+ }
type = HTTP_INTERNAL_SERVER_ERROR;
}
else {
@@ -108,11 +119,6 @@ AP_DECLARE(void) ap_die(int type, request_rec *r)
}
}
- if (type == DONE) {
- ap_finalize_request_protocol(r);
- return;
- }
-
/*
* The following takes care of Apache redirects to custom response URLs
* Note that if we are already dealing with the response to some other
@@ -141,6 +147,10 @@ AP_DECLARE(void) ap_die(int type, request_rec *r)
custom_response = NULL; /* Do NOT retry the custom thing! */
}
+ else {
+ error_index = ap_index_of_response(type);
+ custom_response = ap_response_code_string(r, error_index);
+ }
r->status = type;
@@ -346,7 +356,9 @@ void ap_process_async_request(request_rec *r)
ap_finalize_request_protocol(r);
}
else {
- r->status = HTTP_OK;
+ if (ap_is_HTTP_VALID_RESPONSE(access_status)) {
+ r->status = HTTP_OK;
+ }
ap_die(access_status, r);
}
[END]
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #11 from maapu <ka...@gmail.com> ---
@Yann
But why do we need to call ap_die incase of ap_is_HTTP_VALID_RESPONSE returns
false. Why cant we just call ap_finalize_request_protocol? Will it miss some
cases?
I will try out the patch today
@Eric
printf "POST /index.html HTTP/1.0\r\nContent-Length: 2\r\n\r\nab" | nc x.x.x.x
80
HTTP/1.1 413 Request Entity Too Large
Date: Tue, 21 Jan 2014 03:42:21 GMT
Server: Apache/2.2.3 (CentOS)
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!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.3 (CentOS) Server at x.x.x.x Port 80</address>
</body></html>
<html>
<head>
<meta name="robots" content="noarchive" />
<meta name="googlebot" content="nosnippet" />
</head>
<body>
<div align=center>
<h3>Error! Page cannot be displayed. Please contact service provider for more
details.</h3>
</div>
</body>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Eric Covener <co...@gmail.com> ---
(In reply to maapu from comment #2)
> why is it made invalid?
I described it in a comment and on the mailing list thread.
mod_php, or mod_php + your php script, ignored the error reading the post body
and returned success instead of returning an error. Its output was included
with the queued up error response.
Please don't reopen bugs without providing new information, or your updates are
likely to be ignored.
There may be other modules with this problem, such as the other PR you
commented on, but those cases need to be debugged individually. If the handler
is part of httpd, it's a valid bug report here.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Re: [Bug 56035] Issue with LimitRequestBody
Posted by Kalyana sundaram <ka...@gmail.com>.
Apache behaviour for non php request
command
curl --data "param1=value1¶m2=value2" x.x.x.x/index.html -A firefox -v
Output
> POST /index.html HTTP/1.1
> User-Agent: firefox
> Host: x.x.x.x
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 27out of 27 bytes
< HTTP/1.1 413 Request Entity Too Large
< Date: Mon, 20 Jan 2014 13:50:13 GMT
< Server: Apache/2.2.3 (CentOS)
< Vary: Accept-Encoding
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!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.html<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.3 (CentOS) Server at x.x.x.x Port 80</address>
</body></html>
* Closing connection #0
Logs
localhost:80 x.x.x.x - - 2014-01-20T13:51:10 - 200 200[status] 417 256 -
"-" "POST /index.html HTTP/1.1" "firefox" 30621
Apache behaviour for php request
curl --data "param1=value1¶m2=value2" x.x.x.x/index.php -A firefox -v
> POST /index.php HTTP/1.1
> User-Agent: firefox
> Host:x.x.x.x
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 27out of 27 bytes
< HTTP/1.1 413 Request Entity Too Large
< Date: Mon, 20 Jan 2014 13:51:59 GMT
< Server: Apache/2.2.3 (CentOS)
< Vary: Accept-Encoding
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!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.3 (CentOS) Server at x.x.x.x Port 80</address>
</body></html>
<html>
Hello
</html>
Logs
localhost:80 x.x.x.x - - 2014-01-20T13:52:51 - 200 200 417 210 - "-" "POST
/index.html HTTP/1.1" "firefox" 30611
On Mon, Jan 20, 2014 at 7:08 PM, <bu...@apache.org> wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
>
> Eric Covener <co...@gmail.com> changed:
>
> What |Removed |Added
>
> ----------------------------------------------------------------------------
> Status|REOPENED |NEEDINFO
>
> --- Comment #5 from Eric Covener <co...@gmail.com> ---
> (In reply to Eric Covener from comment #4)
> > Can you duplicate with a non-php testcase?
>
> related: https://issues.apache.org/bugzilla/show_bug.cgi?id=36090
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: bugs-help@httpd.apache.org
>
>
--
Kalyanasundaram
http://blogs.eskratch.com/
https://github.com/kalyanceg/
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |NEEDINFO
--- Comment #5 from Eric Covener <co...@gmail.com> ---
(In reply to Eric Covener from comment #4)
> Can you duplicate with a non-php testcase?
related: https://issues.apache.org/bugzilla/show_bug.cgi?id=36090
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #14 from Eric Covener <co...@gmail.com> ---
maapu, what generates the response for your index.html? Is it diverted to PHP?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #10 from Yann Ylavic <yl...@gmail.com> ---
Created attachment 31233
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31233&action=edit
non-HTTP statuses and ap_die() / ap_process_request()
Patch above attached.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
Yann Ylavic <yl...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #31233|0 |1
is obsolete| |
--- Comment #13 from Yann Ylavic <yl...@gmail.com> ---
Created attachment 31245
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31245&action=edit
non-HTTP statuses and ap_die() / ap_process_request()
The patch described above.
Note that the ap_dies()'s !ap_is_HTTP_VALID_RESPONSE(type) branch now logs an
initial vs recursive error based on r->status, since as Eric said this is not
necessarily a "Custom error page" error here.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #6 from maapu <ka...@gmail.com> ---
Apache behaviour for non php request
command
curl --data "param1=value1¶m2=value2" x.x.x.x/index.html -A firefox -v
Output
> POST /index.html HTTP/1.1
> User-Agent: firefox
> Host: x.x.x.x
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 27out of 27 bytes
< HTTP/1.1 413 Request Entity Too Large
< Date: Mon, 20 Jan 2014 13:50:13 GMT
< Server: Apache/2.2.3 (CentOS)
< Vary: Accept-Encoding
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!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.html<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.3 (CentOS) Server at x.x.x.x Port 80</address>
</body></html>
* Closing connection #0
Logs
localhost:80 x.x.x.x - - 2014-01-20T13:51:10 - 200 200[status] 417 256 - "-"
"POST /index.html HTTP/1.1" "firefox" 30621
Apache behaviour for php request
curl --data "param1=value1¶m2=value2" x.x.x.x/index.php -A firefox -v
> POST /index.php HTTP/1.1
> User-Agent: firefox
> Host:x.x.x.x
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 27out of 27 bytes
< HTTP/1.1 413 Request Entity Too Large
< Date: Mon, 20 Jan 2014 13:51:59 GMT
< Server: Apache/2.2.3 (CentOS)
< Vary: Accept-Encoding
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!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.3 (CentOS) Server at x.x.x.x Port 80</address>
</body></html>
<html>
Hello
</html>
Logs
localhost:80 x.x.x.x - - 2014-01-20T13:52:51 - 200 200 417 210 - "-" "POST
/index.html HTTP/1.1" "firefox" 30611
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #17 from Eric Covener <co...@gmail.com> ---
(In reply to Yann Ylavic from comment #16)
> (In reply to Eric Covener from comment #15)
> > Current rev of patch has a problem with access_status=AP_FILTER_ERROR,
> > ap_die will copy it to r->status, so the caller cannot restore it. Left at
> > a negative value, it's logged as -.
>
> I don't see how, in the proposed patch, ap_die() can set r->status to
> anything than a valid HTTP status (AP_FILTER_ERROR, AP_NOBODY_READ/WROTE or
> whatever).
>
> When the given access_status is not a valid HTTP status (as per
> ap_is_HTTP_VALID_RESPONSE, negative values included), either ap_die() does
> nothing (response already sent), or it is forced to
> HTTP_INTERNAL_SERVER_ERROR (and so will be r->status below).
>
> Do you have a path for this to happen?
You're right, I had to hand-merge parts into 2.2.x and looking now it is
mangled
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56035] Issue with LimitRequestBody
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56035
--- Comment #8 from Eric Covener <co...@gmail.com> ---
How does this do w/ your php test case, making sure to look at the body -- i
suggest using netcat instead of curl/wget since there is some invalid response
issues
e.g. printf "POST /index.html HTTP/1.0\r\nContent-Length: 2\r\n\r\nab" | nc 0
80
(debug left in)
Index: modules/http/http_request.c
===================================================================
--- modules/http/http_request.c (revision 1559612)
+++ modules/http/http_request.c (working copy)
@@ -288,12 +288,15 @@
access_status = OK;
}
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "URI %s, rc=%d, status=%d",
r->uri, access_status, r->status);
+
if (access_status == OK) {
ap_finalize_request_protocol(r);
}
else {
- r->status = HTTP_OK;
+ if (access_status != AP_FILTER_ERROR) r->status = HTTP_OK;
ap_die(access_status, r);
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "after ap_die URI %s,
rc=%d, status=%d", r->uri, access_status, r->status);
}
/*
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org