From: Yann Ylavic Date: Wed, 29 Apr 2015 20:48:17 +0000 (+0000) Subject: Working on it. X-Git-Tag: 2.4.13~146 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=13d1ff0e53db0bef2b0787e6642c29ec96d1d0f9;p=apache Working on it. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1676855 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/STATUS b/STATUS index ce7af3147e..4c5eb1c704 100644 --- a/STATUS +++ b/STATUS @@ -208,33 +208,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.4.x patch: http://people.apache.org/~ylavic/httpd-2.4.x-ap_listeners_buckets.patch +1: ylavic - * mod_proxy_http: Don't establish or reuse a backend connection before pre- - fetching the request body, so to minimize the delay between it is supposed - to be alive and the first bytes sent: this is a best effort to prevent the - backend from closing because of idle or keepalive timeout in the meantime. - Also, handle a new "proxy-flushall" environment variable which allows to - flush any forwarded body data immediately. PR 56541+37920. - trunk patch: http://svn.apache.org/r1656259 - http://svn.apache.org/r1656359 (CHANGES entry) - 2.4.x patch: trunk works (modulo CHANGES, docs/log-message-tags) - +1: ylavic - -0: jim: This seems to be a hit to normal performance, to handle an - error and/or non-normal condition. The pre-fetch is - expensive, and is always done, even before we know that - the backend is available to rec' it. I understand the - error described, but is the fix actually worth it (plus - it seems to allow for a DDoS vector). - ylavic: It seems to me that the problem is real since we reuse the - connection before prefetching 16K (either controlled by the - client, or by an input filter), we currently always prefetch - these bytes already. Regarding performance I don't see any - difference (more cycles) compared with the current code. - However I think I failed to rebuild the header_brigade when - the proxy loop is retried (ping), so I need to rework this. - Do you think we'd better remove the prefetch, or maybe just - make it nonblocking (by default)? - jim: Non-blocking seems the best way to handle... - *) http: Make ap_die() robust against any HTTP error code and not modify response status (finally logged) when nothing is to be done. PR 56035. trunk patch: http://svn.apache.org/r1657881 @@ -318,6 +291,33 @@ OTHER PROPOSALS PATCHES/ISSUES THAT ARE BEING WORKED + * mod_proxy_http: Don't establish or reuse a backend connection before pre- + fetching the request body, so to minimize the delay between it is supposed + to be alive and the first bytes sent: this is a best effort to prevent the + backend from closing because of idle or keepalive timeout in the meantime. + Also, handle a new "proxy-flushall" environment variable which allows to + flush any forwarded body data immediately. PR 56541+37920. + trunk patch: http://svn.apache.org/r1656259 + http://svn.apache.org/r1656359 (CHANGES entry) + 2.4.x patch: trunk works (modulo CHANGES, docs/log-message-tags) + +1: ylavic + -0: jim: This seems to be a hit to normal performance, to handle an + error and/or non-normal condition. The pre-fetch is + expensive, and is always done, even before we know that + the backend is available to rec' it. I understand the + error described, but is the fix actually worth it (plus + it seems to allow for a DDoS vector). + ylavic: It seems to me that the problem is real since we reuse the + connection before prefetching 16K (either controlled by the + client, or by an input filter), we currently always prefetch + these bytes already. Regarding performance I don't see any + difference (more cycles) compared with the current code. + However I think I failed to rebuild the header_brigade when + the proxy loop is retried (ping), so I need to rework this. + Do you think we'd better remove the prefetch, or maybe just + make it nonblocking (by default)? + jim: Non-blocking seems the best way to handle... + PATCHES/ISSUES THAT ARE STALLED