On Mon, Jun 27, 2016 at 11:26 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Mon, Jun 27, 2016 at 10:48 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> >>> Am 27.06.2016 um 10:41 schrieb Yann Ylavic <ylavic....@gmail.com>: >>> >>> On Mon, Jun 27, 2016 at 10:23 AM, Stefan Eissing <ste...@eissing.org> wrote: >>>> This looks nice for HTTP/1.1, but what about other protocols? Do I read it >>>> correctly that any pending data downstream will reopen the connection? >>> >>> Hmm, I did not think about mod_proxy_h2, but correct (I'd rather say >>> upstream though, backend side). >>> Are there cases where some backend data are available before the >>> request is sent? >> >> In HTTP/2, yes. For example a PING frame might be waiting, or a >> SETTINGS change. Most backends will have short timeouts for answers >> to these (SETTINGS is expected to be ACKed soonish), but races may >> happen. Also, HTTP/2 extensions with new frame types that need to be >> ignored when not known may get received here. > > OK, so we probably should get rid of the call to > ap_proxy_ssl_connection_cleanup() in proxy_http2_handler (and also in > proxy_http_handler with my latest changes since the same check is now > available in ap_proxy_check_connection).
I went ahead and committed r1750414 (resp. r1750416). The possible issue if r1750414 were backported, is that without r1750392 mod_proxy_http2 may not detect a TLS close notify before reusing a backend connection. If it's not backported, it may close a legitimate backend connection with (pre-)available data...
