[wp-trac] [WordPress Trac] #25716: HTTP requests fails with "SSL read: error:00000000:lib(0):func(0):reason( 0), errno 0"

[WordPress Trac]

#25716: HTTP requests fails with "SSL read: error:00000000:lib(0):func(0):reason(
0), errno 0"
------------------------------+---------------------
 Reporter:  ocean90           |       Owner:  nacin
     Type:  defect (bug)      |      Status:  closed
 Priority:  highest omg bbq   |   Milestone:  3.7.1
Component:  HTTP              |     Version:  3.7
 Severity:  blocker           |  Resolution:  fixed
 Keywords:  has-patch commit  |
------------------------------+---------------------

Comment (by dd32):

 Replying to [comment:22 scribu]:
 > > Certain versions of cURL appear to claim OpenSSL support but fail to
 work.
 >
 > I don't think that's the whole story. At least for environments with
 GnuTLS, requests made by WP 3.6 work, while requests made by WP 3.7 fail.
 More context: https://github.com/wp-cli/wp-cli/issues/846

 GnuTLS refuses to talk to a standard-configured nginx server over SSL,
 that's the problem with cURL on the travis system. Put basically, when
 cURL is used with OpenSSL it ignores non-fatal SSL errors that nginx can
 trigger, when compiled with GnuTLS however, it cannot determine if it's a
 fatal ssl error or not, and just fails 100% of the time.
 (If you have cURL compiled with GnuTLS on the command line, I doubt that
 can make a POST to https://api.wordpress.org either)

 The context that you're missing, is that in 3.6 all API requests went over
 HTTP, in 3.7 all API requests go over HTTPS if supported else HTTP, and in
 3.7.1 all API requests first go over HTTPS if supported, and fall back to
 HTTP in event of failure (but triggers a PHP Notice/Warning).

 ----

 The tech details:
 The cause problem with cURL 7.31.0 w/ OpenSSL, and with cURL w/ GnuTLS in
 general is caused by the connection shutting down before the SSL
 connection has been properly shutdown, this isn't a fatal issue as the
 data has already been received and sent by both parties - it's simply like
 your great aunt saying goodbye and hugging you another dozen times, nginx
 cuts her off and says get in the car.

 The root cause is that nginx applies a set of heuristics to open
 connections to determine when it believes it can close the connection, and
 closes it before that SSL shutdown handshake is done, so really, it's that
 nginx takes a shortcut that works with every client except GnuTLS (which
 sticks to the standard to a dot - which can be the wrong thing to do when
 dealing with 3rd party software (web servers) ).

 nginx can be configured to not close connections early by using it's
 `lingering_close off;` directive, the problem is that it can affect
 performance in a few unknown cases since it's not documented very well..
 but we're looking into it.

 One can also say it's a bug in nginx's heuristics, and I'd argue that's
 true, since standard HTTPS GET's work, it's just HTTPS POST's that fail.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25716#comment:23>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software