Its this line in the changelog: BUG/MEDIUM: stream interface: fix possible stalls during transfers
The changelog comes from the commit line, but that line explains the fix itself, not the possible symptoms of the bug it addresses. To understand all the details of a change, I suggest your read the commit message [1]. If you are running -dev, its probably a good idea to follow the mailing list closely and eventually read the commit message on git. [1] http://haproxy.1wt.eu/git?p=haproxy.git;a=commit;h=ca00fbcb91165e5d8d64ba7b53000ffac77f44c9 ---------------------------------------- > Date: Fri, 11 Jan 2013 09:13:38 -0800 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: Problems with sni and big connections. > > *Huh*. I looked at the changelog, and there's nothing relevant, so > I didn't try that first. > > I'm curious, is it mentioned and I just don't understand it? > > Regardless, wilco. > > -Robin > > On Fri, Jan 11, 2013 at 10:27:19AM +0100, Lukas Tribus wrote: > > > > There has been a POST bug (among many others) which was fixed in > > -dev16. Please upgrade to latest 1.5-dev17. > > > > > > > > > > ---------------------------------------- > > > Date: Thu, 10 Jan 2013 17:44:07 -0800 > > > From: [email protected] > > > To: [email protected] > > > Subject: Problems with sni and big connections. > > > > > > Context: SSL stuff, haproxy HA-Proxy version 1.5-dev15 2012/12/12 ; > > > complete haproxy info at the bottom. > > > > > > Our app does large file uploads via an ancillary java applet thingy; > > > these look like so: > > > > > > 00000009:https.accept(0006)=000f from [64.236.139.254:35763] > > > 00000009:https.clireq[000f:ffff]: POST /cytobank/uploadServlet HTTP/1.1 > > > 00000009:https.clihdr[000f:ffff]: User-Agent: Cytobank Upload > > > 00000009:https.clihdr[000f:ffff]: Content-Type: multipart/form-data; > > > boundary=756zrpPEjQyIs1KS9cHjGzvox7mMfeCZR0 > > > 00000009:https.clihdr[000f:ffff]: Cache-Control: no-cache > > > 00000009:https.clihdr[000f:ffff]: Pragma: no-cache > > > 00000009:https.clihdr[000f:ffff]: Host: dvs-staging.cytobank.org > > > 00000009:https.clihdr[000f:ffff]: Accept: text/html, image/gif, > > > image/jpeg, *; q=.2, */*; q=.2 > > > 00000009:https.clihdr[000f:ffff]: Connection: keep-alive > > > 00000009:https.clihdr[000f:ffff]: Content-Length: 6451523 > > > 00000009:https.clihdr[000f:ffff]: Cookie: > > > __utma=51498683.1371821700.1307729573.1357763653.1357770695.223; > > > __utmz=51498683.1348737696.200.4.utmcsr=localhost|utmccn=(referral)|utmcmd=referral|utmcct=/cytobank/subscriptions/subscribe; > > > __utma=20047853.812597310.1357601503.1357799042.1357864337.4; > > > __utmz=20047853.1357601503.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); > > > __utmb=20047853.32.10.1357864337; __utmc=20047853; > > > openid_provider=Google; > > > user_credentials=ff9ed09a5a08f5103cdce0bcf9c7eda9d9bcee3e2e5a392b0e0b066780f5cfdb2a505a8bdd17d505057b751b20a96989ed61f6435a057d751958f034c095be50%3A%3A2 > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvrep[000f:0010]: > > > HTTP/1.1 200 OK > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Server: > > > Apache-Coyote/1.1 > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: > > > Content-Type: text/html;charset=ISO-8859-1 > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: > > > Transfer-Encoding: chunked > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Date: > > > Fri, 11 Jan 2013 01:13:19 GMT > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: > > > Connection: close > > > 00000009:https.clicls[000f:ffff] > > > 00000009:https.closed[000f:ffff] > > > > > > I'm using haproxy's ssl, like so: > > > > > > bind 0.0.0.0:443 ssl crt /opt/haproxy/etc/wildcard.cert > > > > > > If the config for this backend is like this: > > > > > > use_backend dvs-staging.cytobank.org-https-tomcat if { path_reg -i > > > ^/cytobank/ } > > > > > > everything works fine, but if it's like this: > > > > > > use_backend dvs-staging.cytobank.org-https-tomcat if { ssl_fc_sni -i > > > dvs-staging.cytobank.org } { path_reg -i ^/cytobank/ } > > > > > > The upload goes very slowly and then fails. > > > > > > There is no obvious difference between the outputs in these cases; > > > the above was successful, this is a failed one: > > > > > > 00000009:https.accept(0006)=000f from [64.236.139.254:45900] > > > 00000009:https.clireq[000f:ffff]: POST /cytobank/uploadServlet HTTP/1.1 > > > 00000009:https.clihdr[000f:ffff]: User-Agent: Cytobank Upload > > > 00000009:https.clihdr[000f:ffff]: Content-Type: multipart/form-data; > > > boundary=qKulbQFAOI0yUOyRv5tJ8Itzvy4aMPqP58 > > > 00000009:https.clihdr[000f:ffff]: Cache-Control: no-cache > > > 00000009:https.clihdr[000f:ffff]: Pragma: no-cache > > > 00000009:https.clihdr[000f:ffff]: Host: dvs-staging.cytobank.org > > > 00000009:https.clihdr[000f:ffff]: Accept: text/html, image/gif, > > > image/jpeg, *; q=.2, */*; q=.2 > > > 00000009:https.clihdr[000f:ffff]: Connection: keep-alive > > > 00000009:https.clihdr[000f:ffff]: Content-Length: 6451523 > > > 00000009:https.clihdr[000f:ffff]: Cookie: > > > __utma=51498683.1371821700.1307729573.1357763653.1357770695.223; > > > __utmz=51498683.1348737696.200.4.utmcsr=localhost|utmccn=(referral)|utmcmd=referral|utmcct=/cytobank/subscriptions/subscribe; > > > __utma=20047853.812597310.1357601503.1357799042.1357864337.4; > > > __utmz=20047853.1357601503.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); > > > __utmb=20047853.28.10.1357864337; __utmc=20047853; > > > openid_provider=Google; > > > user_credentials=ff9ed09a5a08f5103cdce0bcf9c7eda9d9bcee3e2e5a392b0e0b066780f5cfdb2a505a8bdd17d505057b751b20a96989ed61f6435a057d751958f034c095be50%3A%3A2 > > > 00000007:http.clicls[000e:ffff] > > > 00000007:http.closed[000e:ffff] > > > 00000005:https.clicls[000a:ffff] > > > 00000005:https.closed[000a:ffff] > > > 00000002:https.clicls[0009:ffff] > > > 00000002:https.closed[0009:ffff] > > > 00000004:https.clicls[000c:ffff] > > > 00000004:https.closed[000c:ffff] > > > 00000003:https.clicls[000b:ffff] > > > 00000003:https.closed[000b:ffff] > > > 00000001:https.clicls[0008:ffff] > > > 00000001:https.closed[0008:ffff] > > > 00000006:https.clicls[000d:ffff] > > > 00000006:https.closed[000d:ffff] > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvrep[000f:0010]: > > > HTTP/1.1 200 OK > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Server: > > > Apache-Coyote/1.1 > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: > > > Content-Type: text/html;charset=ISO-8859-1 > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: > > > Transfer-Encoding: chunked > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: Date: > > > Fri, 11 Jan 2013 01:08:39 GMT > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvhdr[000f:0010]: > > > Connection: close > > > 00000009:dvs-staging.cytobank.org-https-tomcat.srvcls[000f:0010] > > > 00000009:dvs-staging.cytobank.org-https-tomcat.clicls[000f:0010] > > > 00000009:dvs-staging.cytobank.org-https-tomcat.closed[000f:0010] > > > > > > (all the extra closes are because it took so long, AFAICT). > > > > > > I'm pretty sure this is an haproxy bug. My *guess* is that what's > > > happening is that the first chunk is sni-ing properly, but that > > > everything else on the same keep-alive session is failing the sni > > > check, and effectively getting thrown away. > > > > > > If it's PEBKAC, I'd love some assistance. > > > > > > Thanks! > > > > > > -Robin > > > > > > [rlpowell@ds1007 ~]$ sudo /opt/haproxy/usr/local/sbin/haproxy -vv > > > HA-Proxy version 1.5-dev15 2012/12/12 > > > Copyright 2000-2012 Willy Tarreau <[email protected]> > > > > > > Build options : > > > TARGET = linux26 > > > CPU = generic > > > CC = gcc > > > CFLAGS = -O2 -g -fno-strict-aliasing > > > OPTIONS = USE_OPENSSL=1 USE_PCRE=1 > > > > > > Default settings : > > > maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 > > > > > > Encrypted password support via crypt(3): yes > > > Built without zlib support (USE_ZLIB not set) > > > Compression algorithms supported : identity > > > Built with OpenSSL version : OpenSSL 1.0.1c 10 May 2012 > > > OpenSSL library supports TLS extensions : yes > > > OpenSSL library supports SNI : yes > > > OpenSSL library supports prefer-server-ciphers : yes > > > > > > Available polling systems : > > > epoll : pref=300, test result OK > > > poll : pref=200, test result OK > > > select : pref=150, test result OK > > > Total: 3 (3 usable), will use epoll. > > > > > > > >
