Hi Pierre, On Mon, Sep 24, 2018 at 02:10:21PM +0000, Pierre Cheynier wrote: > > You'll notice that in the HTTP/2 case, the stream is closed as you mentioned > > (DATA len=0 + ES=1) then HAProxy immediately send FIN-ACK to the server. > > Same for the client just after it forwarded the headers. It never wait for > > any > > SSE frame. > > EDIT: in fact, analyzing my capture, I see that my workstation (curl) may be > the > originator, since it sends a close at TLS level (the close-notify).. > > $ curl --version > curl 7.61.0 (x86_64-pc-linux-gnu) libcurl/7.61.0 OpenSSL/1.1.0h zlib/1.2.11 > libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.32.0 > librtmp/2.3 > Release-Date: 2018-07-11 > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 > pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp > Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB > SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL > > curl or haproxy issue? what do you think?
In my experience when fed with a single request, curl closes right after receiving a complete response. You can try to pass it two requests on the same line to see if it only closes at the end. The close on the server side is expected, that's a limitation of the current design that we're addressing for 1.9 and which is much harder than initially expected. The reason is that streams are independent in H2 while in H1 the same stream remains idle and recycled for a new request, allowing us to keep the server-side connection alive. Thus in H2 we can't benefit from the keep-alive mechanisms we have in H1. But we're currently working on addressing this. As a side effect, it should end up considerably simplifying the H1 code as well, but for now it's a nightmare, too many changes at once... Cheers, Willy
