[Bug 53579] httpd looping writing on a pipe and unresponsive (httpd )
https://bz.apache.org/bugzilla/show_bug.cgi?id=53579 --- Comment #13 from Yann Ylavic --- Created attachment 35795 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35795&action=edit Check POD on poll() timeout Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 53579] httpd looping writing on a pipe and unresponsive (httpd )
https://bz.apache.org/bugzilla/show_bug.cgi?id=53579 Paul Ripke changed: What|Removed |Added CC||stix...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 53579] httpd looping writing on a pipe and unresponsive (httpd )
https://bz.apache.org/bugzilla/show_bug.cgi?id=53579 --- Comment #12 from Paul Ripke --- +1. Server version: Apache/2.4.29 (Unix) Server built: Jan 29 2018 09:45:53 Server's Module Magic Number: 20120211:68 Server loaded: APR 1.6.3, APR-UTIL 1.6.1 Compiled using: APR 1.6.3, APR-UTIL 1.6.1 Architecture: 64-bit Server MPM: prefork threaded: no forked: yes (variable process count) NetBSD 8.0_BETA -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62202] Child servers hang in gracefully shutting down state indefinitely
https://bz.apache.org/bugzilla/show_bug.cgi?id=62202 --- Comment #2 from Yann Ylavic --- Looks like it's not really a new issue: https://stackoverflow.com/questions/38315004/apache-2-4-lot-of-stuck-threads-in-w-sending-reply-mode?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62202] Child servers hang in gracefully shutting down state indefinitely
https://bz.apache.org/bugzilla/show_bug.cgi?id=62202 Yann Ylavic changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Yann Ylavic --- Unfortunately a worker thread is blocked (deadlock?) in wl_increment_state_metric() from mod_wl_24, which is closed sources. I suppose that you'll have to ask for support to Oracle... -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62202] New: Child servers hang in gracefully shutting down state indefinitely
https://bz.apache.org/bugzilla/show_bug.cgi?id=62202 Bug ID: 62202 Summary: Child servers hang in gracefully shutting down state indefinitely Product: Apache httpd-2 Version: 2.4.29 Hardware: PC OS: Linux Status: NEW Severity: critical Priority: P2 Component: mpm_event Assignee: bugs@httpd.apache.org Reporter: m...@blackmans.org Target Milestone: --- Created attachment 35794 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35794&action=edit gdb full thread backtrace from a hung child server. I've attached a backtrace and this problem look similar to a couple of others, but in Apache 2.4.32 (the one that didn't get fully announced), we can see that child servers go into stopping mode (gracefully shutting down), but never actually go away. I've attached a backtrace suggesting that weblogic webserver plugin module maybe the one causing the deadlock/hang/freeze, but would like some idea of options from here. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62200] ap_rgetline does not translate lines larger than buffer limit to EBCDIC
https://bz.apache.org/bugzilla/show_bug.cgi?id=62200 Eric Covener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Eric Covener --- Thanks, fixed in trunk and 2.4 with a trivial change to use APR_STATUS_IS_ENOSPC(rv) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62199] Make mod_proxy response header size configurable
https://bz.apache.org/bugzilla/show_bug.cgi?id=62199 Hank Ibell changed: What|Removed |Added Summary|Make mod_proxy response |Make mod_proxy response |buffer's size configurable |header size configurable -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62200] New: ap_rgetline does not translate lines larger than buffer limit to EBCDIC
https://bz.apache.org/bugzilla/show_bug.cgi?id=62200 Bug ID: 62200 Summary: ap_rgetline does not translate lines larger than buffer limit to EBCDIC Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Core Assignee: bugs@httpd.apache.org Reporter: hwib...@gmail.com Target Milestone: --- Created attachment 35792 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35792&action=edit Proposed patch for trunk On EBCDIC systems, translation does not occur in ap_rgetline() if the line is larger than the buffer size. Solution is to also do translation if ap_rgetline_core() returns APR_ENOSPC. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62199] Make mod_proxy response buffer's size configurable
https://bz.apache.org/bugzilla/show_bug.cgi?id=62199 --- Comment #1 from Hank Ibell --- Created attachment 35791 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35791&action=edit Proposed patch for trunk -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62199] New: Make mod_proxy response buffer's size configurable
https://bz.apache.org/bugzilla/show_bug.cgi?id=62199 Bug ID: 62199 Summary: Make mod_proxy response buffer's size configurable Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: enhancement Priority: P2 Component: mod_proxy_http Assignee: bugs@httpd.apache.org Reporter: hwib...@gmail.com Target Milestone: --- Users of mod_proxy may find that the 8K proxy response buffer is not sufficient to hold large headers. This enhancement allows the proxy response buffer to be configurable via the worker parameter 'ResponseFieldSize'. A few bugs were opened for some weird behavior that was observed both before and after applying the patch: - https://bz.apache.org/bugzilla/show_bug.cgi?id=62196 - https://bz.apache.org/bugzilla/show_bug.cgi?id=62197 - https://bz.apache.org/bugzilla/show_bug.cgi?id=62198 Example usage: # Allow proxy headers up to 1 bytes instead of just 8KB. ProxyPass "/test" "http://localhost:8080"; responsefieldsize=1 ProxyPassReverse "/test" "http://localhost:8080"; Backend header size: $ curl -sD - http://localhost:8080 -o /dev/null | grep X-Test-Header-1 | wc -c 9020 Proxy header size: $ curl -sD - http://localhost/test -o /dev/null | grep X-Test-Header-1 | wc -c 9020 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62198] New: ap_rgetline_core can return without consuming a full line
https://bz.apache.org/bugzilla/show_bug.cgi?id=62198 Bug ID: 62198 Summary: ap_rgetline_core can return without consuming a full line Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Core Assignee: bugs@httpd.apache.org Reporter: hwib...@gmail.com Target Milestone: --- When ap_rgetline_core hits its own length limit, it does not continue to loop over the core input filter to make sure a full line is consumed, potentially leaving the trailing portion of a long line to resemble a new line. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62197] New: A HTTP 200 is returned for proxy requests with truncated headers
https://bz.apache.org/bugzilla/show_bug.cgi?id=62197 Bug ID: 62197 Summary: A HTTP 200 is returned for proxy requests with truncated headers Product: Apache httpd-2 Version: 2.5-HEAD Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: mod_proxy_http Assignee: bugs@httpd.apache.org Reporter: hwib...@gmail.com Target Milestone: --- Headers in a proxy response that are greater than 8K are truncated, but still returns a 200. As header data is being lost, I would expect a HTTP 500 response instead of a 200. In the example below, a 200 is being returned even though ~1000 bytes are being lost from X-Test-Header-1. Sample config: ProxyPass "/test" "http://localhost:8080"; ProxyPassReverse "/test" "http://localhost:8080"; Header set X-Test-Header-1 "AAA..." # large header > 8KB Request/response: $ curl -sD - http://localhost/test -o /dev/null HTTP/1.1 200 OK Date: Tue, 20 Mar 2018 15:46:37 GMT Server: Apache/2.5.1-dev (Unix) Last-Modified: Sun, 06 Nov 2016 05:34:43 GMT ETag: "2d-5409b43abe2c0" Accept-Ranges: bytes Content-Length: 45 X-Test-Header-1: ... [truncated] Content-Type: text/html Original header size: $ curl -sD - http://localhost:8080 -o /dev/null | grep X-Test-Header-1 | wc -c 9020 Proxied header size: $ curl -sD - http://localhost/test -o /dev/null | grep X-Test-Header-1 | wc -c 8019 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 62196] New: Proxy response headers can be thrown away after processing a large header
https://bz.apache.org/bugzilla/show_bug.cgi?id=62196
Bug ID: 62196
Summary: Proxy response headers can be thrown away after
processing a large header
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_http
Assignee: bugs@httpd.apache.org
Reporter: hwib...@gmail.com
Target Milestone: ---
Response headers from a proxied request can be thrown away after reading a
large header. If a header exceeds the the buffer size by a small amount -- say
the buffer size is 8 KB and the header is 10 KB -- the next header that is read
will be thrown away.
This looks to be due to ap_rgetline_core throwing away the extra bit of data
when it detects that the buffer would be overrun. ap_proxy_read_headers() in
mod_proxy_http.c then tries to soak up the 'extra data' which was already
thrown away by ap_rgetline_core and causes the next header to be thrown away:
while ((len = ap_getline(field, MAX_STRING_LEN, rr, 1))
>= MAX_STRING_LEN - 1) {
/* soak up the extra data */
}
Removing the while loop does not fix the problem because extra data will be
left from a large header that is at least 3x the proxy response buffer size.
The extra data is then seen as an invalid header and results in a HTTP 502
response.
In the example below, X-Test-Header-2 will be thrown away.
Sample config:
ProxyPass "/test" "http://localhost:8080";
ProxyPassReverse "/test" "http://localhost:8080";
Header set X-Test-Header-1 "AAA..." # large header > 8KB
Header set X-Test-Header-2 "Testing 1 2 3"
Request/response:
$ curl -sD - http://localhost/test -o /dev/null
HTTP/1.1 200 OK
Date: Tue, 20 Mar 2018 15:46:37 GMT
Server: Apache/2.5.1-dev (Unix)
Last-Modified: Sun, 06 Nov 2016 05:34:43 GMT
ETag: "2d-5409b43abe2c0"
Accept-Ranges: bytes
Content-Length: 45
X-Test-Header-1: ... [truncated]
Content-Type: text/html
Backend trace:
[Tue Mar 20 15:46:37.801645 2018] [headers:trace2] [pid 86969:tid
123145425690624] mod_headers.c(880): AH01502: headers:
ap_headers_output_filter()
[Tue Mar 20 15:46:37.801714 2018] [http:trace3] [pid 86969:tid 123145425690624]
http_filters.c(1070): [client ::1:59315] Response sent with status 200,
headers:
[Tue Mar 20 15:46:37.801767 2018] [http:trace5] [pid 86969:tid 123145425690624]
http_filters.c(1079): [client ::1:59315] Date: Tue, 20 Mar 2018 15:46:37 GMT
[Tue Mar 20 15:46:37.801790 2018] [http:trace5] [pid 86969:tid 123145425690624]
http_filters.c(1082): [client ::1:59315] Server: Apache/2.5.1-dev (Unix)
[Tue Mar 20 15:46:37.801889 2018] [http:trace4] [pid 86969:tid 123145425690624]
http_filters.c(900): [client ::1:59315] Last-Modified: Sun, 06 Nov 2016
05:34:43 GMT
[Tue Mar 20 15:46:37.801915 2018] [http:trace4] [pid 86969:tid 123145425690624]
http_filters.c(900): [client ::1:59315] ETag: \\"2d-5409b43abe2c0\\"
[Tue Mar 20 15:46:37.801931 2018] [http:trace4] [pid 86969:tid 123145425690624]
http_filters.c(900): [client ::1:59315] Accept-Ranges: bytes
[Tue Mar 20 15:46:37.801944 2018] [http:trace4] [pid 86969:tid 123145425690624]
http_filters.c(900): [client ::1:59315] Content-Length: 45
[Tue Mar 20 15:46:37.801972 2018] [http:trace4] [pid 86969:tid 123145425690624]
http_filters.c(900): [client ::1:59315] X-Test-Header-1: ...
[Tue Mar 20 15:46:37.802032 2018] [http:trace4] [pid 86969:tid 123145425690624]
http_filters.c(900): [client ::1:59315] X-Test-Header-2: Testing 1 2 3
Proxy trace:
[Tue Mar 20 15:46:37.805911 2018] [http:trace3] [pid 86970:tid 123145344696320]
http_filters.c(1070): [client ::1:59314] Response sent with status 200,
headers:
[Tue Mar 20 15:46:37.805926 2018] [http:trace5] [pid 86970:tid 123145344696320]
http_filters.c(1079): [client ::1:59314] Date: Tue, 20 Mar 2018 15:46:37 GMT
[Tue Mar 20 15:46:37.805938 2018] [http:trace5] [pid 86970:tid 123145344696320]
http_filters.c(1082): [client ::1:59314] Server: Apache/2.5.1-dev (Unix)
[Tue Mar 20 15:46:37.805952 2018] [http:trace4] [pid 86970:tid 123145344696320]
http_filters.c(900): [client ::1:59314] Last-Modified: Sun, 06 Nov 2016
05:34:43 GMT
[Tue Mar 20 15:46:37.805964 2018] [http:trace4] [pid 86970:tid 123145344696320]
http_filters.c(900): [client ::1:59314] ETag: \\"2d-5409b43abe2c0\\"
[Tue Mar 20 15:46:37.805976 2018] [http:trace4] [pid 86970:tid 123145344696320]
http_filters.c(900): [client ::1:59314] Accept-Ranges: bytes
[Tue Mar 20 15:46:37.805987 2018] [http:trace4] [pid 86970:tid 123145344696320]
http_filters.c(900): [client ::1:59314] Content-Length: 45
[Tue Mar 20 15:46:37.806009 2018] [http:trace4] [pid 86970:tid 123145344696320]
http_filters.c(900): [client ::1:59314] X-Test-Header-1: ...
[Tue Mar 20 15:46:37.806057 2018] [http:trace4] [pid 86970:tid 123145344696320]
http_filters.c(900): [client ::1:59314] Content-Ty
[Bug 61616] mod_proxy_connect: stall and connection loss on bi-directional traffic
https://bz.apache.org/bugzilla/show_bug.cgi?id=61616 Yann Ylavic changed: What|Removed |Added Attachment #35783|0 |1 is obsolete|| Attachment #35784|0 |1 is obsolete|| --- Comment #70 from Yann Ylavic --- Created attachment 35789 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35789&action=edit Handle POLLOUT in proxy_connect (v13) Previous patch (v12) was bogus, indeed. This new one should work regardless of THRESHOLD_MIN_WRITE (or FlushMinThreshold from attachment 35620), i.e. it's really self contained. The does use or play with "data_in_input_filters" because the core filter can't be responsible for clearing it (other filters might retain data too, suppose it's used by third-party modules...). So I kept my "drain" flag, set according to ap_proxy_transfer_between_connections() since a successful return from there implies that there is no pending data. It allows to reduce pressure on buffering as you noted, but mainly to avoid blocking on the write side of ap_proxy_transfer_between_connections() by progressively accumulating data there, should it not "follow" the read side (which defeats the purpose of checking data_in_output_filters anyway). I tries to keep the best of our respective proposals (no buffering nor code duplication...), if it works we should find an agreement right? :) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
