Re: Time for 2.4.11
On 2015-01-08 12:11, Jim Jagielski wrote: Let's shoot for a TR next week. The work will keep me warm :) Perhaps you can take a look into this two bug id's: - https://issues.apache.org/bugzilla/show_bug.cgi?id=53824 contains a corrected fix (use correct '[[1234]].*' instead single '[1234].*' ) and this one if build with dynamic modules. - https://issues.apache.org/bugzilla/show_bug.cgi?id=53882 -- Regards, olli
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 4:38 AM, Ewald Dieterich ew...@mailbox.org wrote:
Any ideas how to fix this so that this situation is handled as a single
error and not as two errors mixed up?
in mod_proxy.c you will see at least 1 stanza like this:
status = ap_get_brigade(r-input_filters, temp_brigade,
AP_MODE_READBYTES, APR_BLOCK_READ,
MAX_MEM_SPOOL - bytes_read);
if (status != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r, APLOGNO(01095)
prefetch request body failed to %pI (%s)
from %s (%s),
p_conn-addr, p_conn-hostname ? p_conn-hostname: ,
c-client_ip, c-remote_host ? c-remote_host: );
return HTTP_BAD_REQUEST;
}
The proper pattern in 2.4.x and later is to not return an error like that:
return ap_map_http_request_error(status, HTTP_BAD_REQUEST);
In the case of that -102 error, the -102 will be returned verbatim
instead (AP_FILTER_ERROR). Are you able to test and verify?
--
Eric Covener
cove...@gmail.com
Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
I set up a simple reverse proxy with Apache 2.4.10 on Debian unstable: ProxyPass / http://backend/ ProxyPassreverse / http://backend/ When I send a request to the reverse proxy with an invalid Content-Length header, I get two 413 and 400 response bodies concatenated: $ curl -i -H Content-Length: a http://frontend/ HTTP/1.1 413 Request Entity Too Large Date: Thu, 08 Jan 2015 09:00:33 GMT Server: Apache/2.4.10 (Debian) Connection: close Content-Type: text/html; charset=iso-8859-1 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title413 Request Entity Too Large/title /headbody h1Request Entity Too Large/h1 The requested resourcebr //br / does not allow request data with GET requests, or the amount of data provided in the request exceeds the capacity limit. hr addressApache/2.4.10 (Debian) Server at frontend Port 80/address /body/html !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title400 Bad Request/title /headbody h1Bad Request/h1 pYour browser sent a request that this server could not understand.br / /p hr addressApache/2.4.10 (Debian) Server at frontend Port 80/address /body/html Even though the HTTP status code in the response is 413, the access log shows a 400 error: [...] GET / HTTP/1.1 400 904 - curl/7.26.0 I think that first a 413 error is created that later gets replaced partly by a 400 error. Here are some log entries: [...] AH01587: Invalid Content-Length = That's where a 413 (HTTP_REQUEST_ENTITY_TOO_LARGE) is created. [...] (-102)Unknown error -102: [client 10.128.128.95:46000] AH01095: prefetch request body failed to 10.8.19.114:80 (frontend) from 10.128.128.95 () = That's were where a 400 (HTTP_BAD_REQUEST) is returned. Any ideas how to fix this so that this situation is handled as a single error and not as two errors mixed up?
Time for 2.4.11
Let's shoot for a TR next week. The work will keep me warm :)
RE: Time for 2.4.11
Hi All, Can we make the SO_REUSEPORT support into this new stable version? The first version of the patch was trunked last June. After tests and modifications, I think it is ready to go. Please let me know what you think. Thanks, Yingqi -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Thursday, January 08, 2015 3:12 AM To: httpd Subject: Time for 2.4.11 Let's shoot for a TR next week. The work will keep me warm :)
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 6:17 PM, Eric Covener cove...@gmail.com wrote: On Thu, Jan 8, 2015 at 12:12 PM, Yann Ylavic ylavic@gmail.com wrote: Also, it seems that ap_map_http_request_error() would better map AP_FILTER_ERROR to DONE, any issue with this? Does that affect ap_die adversely? It can no longer tell the difference. As we already discussed in [1] and [2], we'd probably handle AP_FILTER better in ap_die() and apply patch [3], so that we don't have to bother whether a handler returns DONE or AP_FILTER_ERROR, ap_die() should do the right thing (ie. nothing if AP_FILTER_ERROR already generated a response). [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201401.mbox/%3CCALK=YjMb2DHo415PuAt4_DsBjXFsvB-ag=qjixx6uclhn62...@mail.gmail.com%3E [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=56035 [3] http://issues.apache.org/bugzilla/attachment.cgi?id=31245
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 12:29 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jan 8, 2015 at 6:17 PM, Eric Covener cove...@gmail.com wrote: On Thu, Jan 8, 2015 at 12:12 PM, Yann Ylavic ylavic@gmail.com wrote: Also, it seems that ap_map_http_request_error() would better map AP_FILTER_ERROR to DONE, any issue with this? Does that affect ap_die adversely? It can no longer tell the difference. As we already discussed in [1] and [2], we'd probably handle AP_FILTER better in ap_die() and apply patch [3], so that we don't have to bother whether a handler returns DONE or AP_FILTER_ERROR, ap_die() should do the right thing (ie. nothing if AP_FILTER_ERROR already generated a response). [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201401.mbox/%3CCALK=YjMb2DHo415PuAt4_DsBjXFsvB-ag=qjixx6uclhn62...@mail.gmail.com%3E [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=56035 [3] http://issues.apache.org/bugzilla/attachment.cgi?id=31245 I am not following (the existing) AH01579. Why is it related to a custom error page at that point?
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On 01/08/2015 01:39 PM, Eric Covener wrote:
On Thu, Jan 8, 2015 at 4:38 AM, Ewald Dieterich ew...@mailbox.org wrote:
Any ideas how to fix this so that this situation is handled as a single
error and not as two errors mixed up?
in mod_proxy.c you will see at least 1 stanza like this:
status = ap_get_brigade(r-input_filters, temp_brigade,
AP_MODE_READBYTES, APR_BLOCK_READ,
MAX_MEM_SPOOL - bytes_read);
if (status != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r, APLOGNO(01095)
prefetch request body failed to %pI (%s)
from %s (%s),
p_conn-addr, p_conn-hostname ? p_conn-hostname:
,
c-client_ip, c-remote_host ? c-remote_host: );
return HTTP_BAD_REQUEST;
}
The proper pattern in 2.4.x and later is to not return an error like that:
return ap_map_http_request_error(status, HTTP_BAD_REQUEST);
In the case of that -102 error, the -102 will be returned verbatim
instead (AP_FILTER_ERROR). Are you able to test and verify?
Hope I tested the right thing. ap_map_http_request_error() is not
available in 2.4.x, so I added it from trunk and replaced the return
statements in the stanzas above as suggested. I attached a patch with my
changes to 2.4.10.
The response looks good now:
$ curl -i -H Content-Length: a http://frontend/
HTTP/1.1 413 Request Entity Too Large
Date: Thu, 08 Jan 2015 14:22:09 GMT
Server: Apache/2.4.10 (Debian)
Connection: close
Content-Type: text/html; charset=iso-8859-1
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title413 Request Entity Too Large/title
/headbody
h1Request Entity Too Large/h1
The requested resourcebr //br /
does not allow request data with GET requests, or the amount of data
provided in
the request exceeds the capacity limit.
hr
addressApache/2.4.10 (Debian) Server at frontend Port 80/address
/body/html
But the access log entry is still wrong. Now a 200 is logged:
[...] GET / HTTP/1.1 200 590 - curl/7.26.0
I still see the -102 error:
[...] (-102)Unknown error -102: [client 10.128.128.95:46766] AH01095:
prefetch request body failed to 10.8.19.114:80 (backend) from
10.128.128.95 ()
I guess there are more changes in trunk that I would need to add?
--- a/modules/proxy/mod_proxy_http.c
+++ b/modules/proxy/mod_proxy_http.c
@@ -324,7 +324,7 @@
from %s (%s), p_conn-addr,
p_conn-hostname ? p_conn-hostname: ,
c-client_ip, c-remote_host ? c-remote_host: );
-return HTTP_BAD_REQUEST;
+return ap_map_http_request_error(status, HTTP_BAD_REQUEST);
}
}
@@ -475,7 +475,7 @@
from %s (%s), p_conn-addr,
p_conn-hostname ? p_conn-hostname: ,
c-client_ip, c-remote_host ? c-remote_host: );
-return HTTP_BAD_REQUEST;
+return ap_map_http_request_error(status, HTTP_BAD_REQUEST);
}
}
@@ -624,7 +624,7 @@
from %s (%s), p_conn-addr,
p_conn-hostname ? p_conn-hostname: ,
c-client_ip, c-remote_host ? c-remote_host: );
-return HTTP_BAD_REQUEST;
+return ap_map_http_request_error(status, HTTP_BAD_REQUEST);
}
}
@@ -807,7 +807,7 @@
from %s (%s),
p_conn-addr, p_conn-hostname ? p_conn-hostname: ,
c-client_ip, c-remote_host ? c-remote_host: );
-return HTTP_BAD_REQUEST;
+return ap_map_http_request_error(status, HTTP_BAD_REQUEST);
}
apr_brigade_length(temp_brigade, 1, bytes);
--- a/include/http_protocol.h
+++ b/include/http_protocol.h
@@ -502,6 +502,23 @@
*/
AP_DECLARE(long) ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz);
+/*
+ * Map specific APR codes returned by the filter stack to HTTP error
+ * codes, or the default status code provided. Use it as follows:
+ *
+ * return ap_map_http_request_error(rv, HTTP_BAD_REQUEST);
+ *
+ * If the filter has already handled the error, AP_FILTER_ERROR will
+ * be returned, which is cleanly passed through.
+ *
+ * These mappings imply that the filter stack is reading from the
+ * downstream client, the proxy will map these codes differently.
+ * @param rv APR status code
+ * @param status Default HTTP code should the APR code not be recognised
+ * @return Mapped HTTP status code
+ */
+AP_DECLARE(int) ap_map_http_request_error(apr_status_t rv, int status);
+
/**
* In HTTP/1.1, any method can have a body. However, most GET handlers
* wouldn't know what to do with a request body if they received one.
--- a/modules/http/http_filters.c
+++ b/modules/http/http_filters.c
@@ -1416,6 +1416,42 @@
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 3:47 PM, Ewald Dieterich ew...@mailbox.org wrote: But the access log entry is still wrong. Now a 200 is logged: [...] GET / HTTP/1.1 200 590 - curl/7.26.0 I still see the -102 error: [...] (-102)Unknown error -102: [client 10.128.128.95:46766] AH01095: prefetch request body failed to 10.8.19.114:80 (backend) from 10.128.128.95 () I guess there are more changes in trunk that I would need to add? Can you test this (attached) patch please (without yours applied)? Regards, Yann. httpd-2.4.x-mod_proxy-AP_FILTER_ERROR.patch Description: application/download
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 4:11 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jan 8, 2015 at 3:47 PM, Ewald Dieterich ew...@mailbox.org wrote: But the access log entry is still wrong. Now a 200 is logged: [...] GET / HTTP/1.1 200 590 - curl/7.26.0 I still see the -102 error: [...] (-102)Unknown error -102: [client 10.128.128.95:46766] AH01095: prefetch request body failed to 10.8.19.114:80 (backend) from 10.128.128.95 () I guess there are more changes in trunk that I would need to add? Can you test this (attached) patch please (without yours applied)? Or with yours and just changing return ap_map_http_request_error(status, HTTP_BAD_REQUEST); by return (status == AP_FILTER_ERROR) ? DONE : ap_map_http_request_error(status, HTTP_BAD_REQUEST); Regards, Yann.
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 9:47 AM, Ewald Dieterich ew...@mailbox.org wrote: Hope I tested the right thing. ap_map_http_request_error() is not available in 2.4.x, so I added it from trunk and replaced the return statements in the stanzas above as suggested. I attached a patch with my changes to 2.4.10. Sorry, I did not realize it was trunk-only. I see Yann replied while I had this in draft -- sorry for the misfire.
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 5:29 PM, Ewald Dieterich ew...@mailbox.org wrote: Looks good. I tested both your patch and my modified one and now error response and access log entry are both OK. Thanks Ewald for testing. Eric, all proxy modules concerned in trunk could be fixed with (status == AP_FILTER_ERROR) ? DONE : ap_map_http_request_error(status, HTTP_BAD_REQUEST), but not 2.4.x where (status == AP_FILTER_ERROR) ? DONE : HTTP_BAD_REQUEST) is a simple fix. Should we also (propose to )backport to 2.4.x the whole ap_map_http_request_error() stuff (r1482522 + r1529991 + r1482918, quite huge...) so that we don't lose specific errors returned by ap_http_filter (ie. turned to 400), or is the simple fix OK?
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 12:08 PM, Yann Ylavic ylavic@gmail.com wrote: Eric, all proxy modules concerned in trunk could be fixed with (status == AP_FILTER_ERROR) ? DONE : ap_map_http_request_error(status, HTTP_BAD_REQUEST), but not 2.4.x where (status == AP_FILTER_ERROR) ? DONE : HTTP_BAD_REQUEST) is a simple fix. Should we also (propose to )backport to 2.4.x the whole ap_map_http_request_error() stuff (r1482522 + r1529991 + r1482918, quite huge...) so that we don't lose specific errors returned by ap_http_filter (ie. turned to 400), or is the simple fix OK? my own 2 cents -- would prefer to maintain the commonality.
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 6:08 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jan 8, 2015 at 5:29 PM, Ewald Dieterich ew...@mailbox.org wrote: Looks good. I tested both your patch and my modified one and now error response and access log entry are both OK. Thanks Ewald for testing. Eric, all proxy modules concerned in trunk could be fixed with (status == AP_FILTER_ERROR) ? DONE : ap_map_http_request_error(status, HTTP_BAD_REQUEST), but not 2.4.x where (status == AP_FILTER_ERROR) ? DONE : HTTP_BAD_REQUEST) is a simple fix. Should we also (propose to )backport to 2.4.x the whole ap_map_http_request_error() stuff (r1482522 + r1529991 + r1482918, quite huge...) so that we don't lose specific errors returned by ap_http_filter (ie. turned to 400), or is the simple fix OK? Also, it seems that ap_map_http_request_error() would better map AP_FILTER_ERROR to DONE, any issue with this?
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 12:12 PM, Yann Ylavic ylavic@gmail.com wrote: Also, it seems that ap_map_http_request_error() would better map AP_FILTER_ERROR to DONE, any issue with this? Does that affect ap_die adversely? It can no longer tell the difference.
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On 01/08/2015 04:15 PM, Yann Ylavic wrote: Can you test this (attached) patch please (without yours applied)? Or with yours and just changing return ap_map_http_request_error(status, HTTP_BAD_REQUEST); by return (status == AP_FILTER_ERROR) ? DONE : ap_map_http_request_error(status, HTTP_BAD_REQUEST); Looks good. I tested both your patch and my modified one and now error response and access log entry are both OK.
Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
On Thu, Jan 8, 2015 at 1:02 PM, Eric Covener cove...@gmail.com wrote: I am not following (the existing) AH01579. Why is it related to a custom error page at that point? http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?r1=722213r2=722212pathrev=722213 There is a short thread responding to the commit email. I think it's a good check minus the custom errordocument slant, and I think I agree with Yann's remix of it where we just do this check any time we ap_die with a non-HTTP status before headers have been written. I think currently this branch should be pretty rare, as ap_invoke_handler is filtering this status code for most places we'd expect it to show up. A non-handler hook or filter returning it directly are the other paths. Those seem unlikely to pass it to ap_die(). -- Eric Covener cove...@gmail.com
AW: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up
-Ursprüngliche Nachricht- Von: Eric Covener [mailto:cove...@gmail.com] Gesendet: Donnerstag, 8. Januar 2015 19:03 An: Apache HTTP Server Development List Betreff: Re: Reverse proxy: invalid Content-Length leads to 413 + 400 errors mixed up On Thu, Jan 8, 2015 at 12:29 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jan 8, 2015 at 6:17 PM, Eric Covener cove...@gmail.com wrote: On Thu, Jan 8, 2015 at 12:12 PM, Yann Ylavic ylavic@gmail.com wrote: Also, it seems that ap_map_http_request_error() would better map AP_FILTER_ERROR to DONE, any issue with this? Does that affect ap_die adversely? It can no longer tell the difference. As we already discussed in [1] and [2], we'd probably handle AP_FILTER better in ap_die() and apply patch [3], so that we don't have to bother whether a handler returns DONE or AP_FILTER_ERROR, ap_die() should do the right thing (ie. nothing if AP_FILTER_ERROR already generated a response). [1] http://mail-archives.apache.org/mod_mbox/httpd- dev/201401.mbox/%3CCALK=YjMb2DHo415PuAt4_DsBjXFsvB- ag=qjixx6uclhn62...@mail.gmail.com%3E [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=56035 [3] http://issues.apache.org/bugzilla/attachment.cgi?id=31245 I am not following (the existing) AH01579. Why is it related to a custom error page at that point? Me neither. Regards Rüdiger
