[wp-trac] [WordPress Trac] #26010: SSL via `WP_Http_Curl` breaks on HTTP version mismatch

[WordPress Trac]

#26010: SSL via `WP_Http_Curl` breaks on HTTP version mismatch
--------------------------+-----------------------------
 Reporter:  soulseekah    |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  HTTP          |    Version:  3.7
 Severity:  minor         |   Keywords:
--------------------------+-----------------------------
 Requesting https://www.google.com on 3.6.1 works fine, while 3.7 and on
 breaks things.

 Located breaking changeset to [25303]. Around line 1232 a cURL error is
 being caught and things bail out. In my case the error is
 `CURLE_RECV_ERROR (56)`, the message is `SSL read:
 error:00000000:lib(0):func(0):reason(0), errno 0` (it's irrelevant, the
 code is relevant).

 Possibly #25716 is related. The error doesn't happen for most sites I
 tried:

 https://github.com works
 https://www.paypal.com works
 https://wordpress.com works
 https://www.sandbox.paypal.com doesn't work
 https://www.google.de doesn't work
 https://www.youtube.com doesn't work

 Moreover, both `stream_headers`
 (http://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-
 http.php?rev=25303#L1289) and `stream_body`
 (http://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-
 http.php?rev=25303#L1303) contain the data of sites that "don't work". At
 both these points `curl_errno` returns `0` (`curl_error` returns and empty
 string).  But after `curl_exec`
 (http://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-
 http.php?rev=25303#L1235) the error is set.

 Previously this error wasn't being caught. The body and the headers and
 everything else were available and ready to use. As of [25303] the error
 is caught and even though the data has been received, the whole thing
 bails out.

 After a lot of digging and experiments I was able to reproduce the
 `CURLE_RECV_ERROR (56)` error by explicitly setting `CURLOPT_HTTP_VERSION`
 to 1.0 (the same behavior http://core.trac.wordpress.org/browser/trunk/src
 /wp-includes/class-http.php?rev=25303#L1209). Setting this to 1.0 for some
 sites results in the error being generated. When removing the option,
 setting it to 1.1 or setting it to `CURL_HTTP_VERSION_NONE` no errors
 occur.



 PHP 5.5.5 (cli) (built: Oct 16 2013 05:59:03) --with-curl=shared
 (x86_64-unknown-linux-gnu) libcurl/7.31.0 OpenSSL/1.0.1e zlib/1.2.8
 libssh2/1.4.3

 This might be broken behavior of the latest libraries, but is there any
 reason to not have cURL decide the version itself? By not setting the
 version now that that error is being caught?

--
Ticket URL: <http://core.trac.wordpress.org/ticket/26010>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software