ab has trouble receiving responses from many HTTPS non-Apache servers (IIS 6.0, Lotus Domino, Google gws), complaining that "SSL read failed": $ ./ab https://www.google.com/ ... This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.google.com (be patient)...SSL read failed - closing connection ..done Those servers seem to terminate TCP connection after the response without shutting down SSL session properly (using close_notify). A possible workaround is to stop reading after Content-Length bytes have been received. I have implemented that that workaround (see the attachment). It appears to work in most cases, the only notable exception is Google gws because it does not send Content-Length in responses to HTTP/1.0 request. Trunk (2.3) appears to be affected too.
Created attachment 25520 [details] proposed patch
HI, i experienced the same problem with the apache2-utils package version 2.2.16-1ubuntu3.1 installed on my maverick machine. I get the following output from ab: This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking www.google.com (be patient)...SSL read failed - closing connection ..done Server Software: gws Server Hostname: www.google.com Server Port: 443 SSL/TLS Protocol: TLSv1/SSLv3,RC4-SHA,1024,128 Document Path: / Document Length: 0 bytes Concurrency Level: 1 Time taken for tests: 0.205 seconds Complete requests: 1 Failed requests: 1 (Connect: 0, Receive: 0, Length: 1, Exceptions: 0) Write errors: 0 Non-2xx responses: 1 Total transferred: 840 bytes HTML transferred: 226 bytes Requests per second: 4.89 [#/sec] (mean) Time per request: 204.524 [ms] (mean) Time per request: 204.524 [ms] (mean, across all concurrent requests) Transfer rate: 4.01 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 152 152 0.0 152 152 Processing: 52 52 0.0 52 52 Waiting: 52 52 0.0 52 52 Total: 204 204 0.0 204 204 I haven't check the newer versions of ab, since i haven't got a system ready to build apache on my own. Is there any progress on this issue? Regards, Andreas
Created attachment 28435 [details] Updated patch for 2.4.1 Confirmed that this bug still exists in the 2.4.1 release. Updated the patch for 2.4.1 and it's working for me now. Any chance we could get this committed to trunk?
Upon further testing, I've found some sites this still doesn't work on. In particular, I've verified that ab will now work fine with -n1 against https://www.google.com/ and https://www.facebook.com/, but will fail with -n2 or higher. The failure modes seem slightly different but both Google and Facebook "cheat" in various ways for performance (such as defeating slow-start) so I'm not too surprised this fails on those two. (Other Google properties, such as https://gmail.com/, work fine.) In testing against most sites I monitor in production it works fine. This represents a mix of Apache, IIS, nginx, and F5 BigIP HTTPS servers. I have found one Tomcat 5.5 that fails, unfortunately this may be exposing a serious error. The first request resolves with a 200, then subsequent requests seem to be continuing the data flow from that first request and interpreting it as a 500. Note that the function (this was with -v2, the failure happens in a part of the page that has JavaScript so that's just page data) is cut off in the middle by a 500 response code. Not sure what's going on. function popWindowSecure(url,winnam WARNING: Response code not 2xx (500) LOG: header received: e,width,height)
Created attachment 28564 [details] Patch for ab to stop "SSL read failed" This is another patch for making ab work with SSL. Also includes the removal of unnecessary apr_socket_bind() call, and the version string of ab will include the openssl version with this patch.
I don't think watching Content-Length on http layer is good idea. Content-Length on http does not always exist because there are other mechanism like "Transfer-Encoding: chunked" or like "100 Continue" or something, even if the http layer is enough neat and honest. We can still take care of chunked coding, but it seems meaningless because the server still can respond incorrectly. Generally they are sloppy and unreliable. My patch is easy one which just treats zero-byte read as the end of communication.
(In reply to comment #4) Does the problem with Tomcat occur when keepalive is NOT enabled? (In reply to comment #6) 1. ab sends HTTP/1.0 requests. See RFC 2616 (a) 3.6 Transfer Codings: "A server MUST NOT send transfer-codings to an HTTP/1.0 client." (b) 8.2.3 Use of the 100 (Continue) Status: "An origin server ... MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client." 2. Indeed, a server can respond incorrectly. Such a server is broken.
Bump. We're experiencing a lot of SSL write failed and some read failed. Not sure if it's the same issue. Anyways, last entry was from APR-18, has this been integrated/what's the status?
Created attachment 30307 [details] update of patch attachment ID # 28564, with failed hunks removed A couple of hunks in patch attachment ID # 28564 were failing due to some changes in the code. So I stripped these out to get it applying again on my system to httpd-2.2.22. Can we please figure out what we need to do to get this finished and merged? Right now it's crippling a tried and true utility that's survived for ages, and it's kind of sad to watch. Let me know if I can help, too!
IMHO fixed in 2.4.x via r1373084.