On Tue, Jun 28, 2016 at 12:11 AM, Yann Ylavic <[email protected]> wrote: > On Mon, Jun 27, 2016 at 11:26 PM, Yann Ylavic <[email protected]> wrote: >> On Mon, Jun 27, 2016 at 10:48 AM, Stefan Eissing >> <[email protected]> wrote: >>> >>>> Am 27.06.2016 um 10:41 schrieb Yann Ylavic <[email protected]>: >>>> >>>> On Mon, Jun 27, 2016 at 10:23 AM, Stefan Eissing <[email protected]> >>>> 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...
I meant: it may discard (pre-)available data (not closing the connection).
