Commit 735faf58 authored by Yann Ylavic's avatar Yann Ylavic
Browse files

Working on it. 

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1676855 13f79535-47bb-0310-9956-ffa450edef68
parent ff04e851

STATUS

+27 −27
Changes for STATUS: 27 added lines, 27 removed lines.
Original line number Diff line number Diff line
@@ -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