httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From yla...@apache.org
Subject svn commit: r1676855 - /httpd/httpd/branches/2.4.x/STATUS
Date Wed, 29 Apr 2015 20:48:18 GMT
Author: ylavic
Date: Wed Apr 29 20:48:17 2015
New Revision: 1676855

URL: http://svn.apache.org/r1676855
Log:
Working on it.

Modified:
    httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1676855&r1=1676854&r2=1676855&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Wed Apr 29 20:48:17 2015
@@ -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
 



Mime
View raw message