rockyjvec

Strange. At this point I can reliably trigger the error using only the delay.php script. I simply use curl or wget to access delay.php and then interrupt it with Ctrl+C. When using ssl it throws the 500 error, when using plain http it returns 200. It only happens when I make the request on the server that is hosting delay.php. If I try the same thing from outside of the server both return the 200 response.

I created a new thread on the Ubuntu forums hoping someone else has had this issue before but so far there are no responses.

https://ubuntuforums.org/showthread.php?t=2277794

This is a tough one. At this point I don’t think it is a WordPress bug. I’ve narrowed the issue down to these two scripts:

test.php:

<?php

$c = curl_init("https://[your-site-here]/delay.php");
curl_setopt($c, CURLOPT_TIMEOUT, 1);
curl_exec($c);

delay.php:

<?php

sleep(2);

If you use https to access delay.php in test.php, it throws the 500 error. If you use http, it gives a normal 200.

I think it’s an issue in either php5-fpm, apache, or the fastcgi module. I tried using tcpdump to look at the communication between php5-fpm and apache but so far I haven’t been able to figure anything out.

It’s something to do with the way wordpress/curl handles ssl. I’ve created a script that I can use for testing:

<?php

require( dirname( __FILE__ ) . '/wp-config.php' );

$options = array (
  0 => 'https://site/test.php',
  1 =>
  array (
    'method' => 'POST',
    'timeout' => 0.01,
    'redirection' => 5,
    'httpversion' => '1.0',
    'user-agent' => 'WordPress/4.2.2; https://site',
    'reject_unsafe_urls' => false,
    'blocking' => false,
    'headers' =>
    array (
      'Accept-Encoding' => 'deflate;q=1.0, compress;q=0.5, gzip;q=0.5',
      'Content-Length' => 0,
    ),
    'cookies' =>
    array (
    ),
    'body' => NULL,
    'compress' => false,
    'decompress' => true,
    'sslverify' => false,
    'sslcertificates' => 'site-path/wp-includes/certificates/ca-bundle.crt',
    'stream' => false,
    'filename' => NULL,
    'limit_response_size' => NULL,
    '_redirection' => 5,
    'ssl' => true,
    'local' => true,
  ),
);

$curl = new WP_HTTP_Curl;

var_dump($curl->request($options[0], $options[1]));

The test.php script referenced above simply sleeps for 2 seconds to trigger the timeout.

If I use the url: https://site/test.php then it times out but the webserver returns a code 200. If I use the url: https://site/test.php then it times out but the webserver returns a code 500. So something is different between how ssl and non-ssl are handled by WordPress’s WP_HTTP_Curl class.

Are you using BackupBuddy? I think the error only occurs for me when scheduled backups occur. I’ve found that I can trigger the error on demand when I manually do a BackupBuddy backup..

I traced the error back to a curl error: “Operation timed out after 1001 milliseconds with 0 bytes received”. Maybe there is something that changed with curl or the way wordpress uses it relating to timeouts.

I have also tried putting the sites into the hosts file with no success.

I wonder if this is a php-curl/loopback issue combined with ssl. I think wp-cron might use that. One of my sites is using the alternate cron (define(‘ALTERNATE_WP_CRON’, true); in wp-config.php) and it does not have the issue.

I’m having the exact same issue on a couple of my sites on Ubuntu 14.04.2/Apache 2.4.7/PHP-FPM 5.5.9/WordPress 4.2.2.

It wasn’t happening before I changed the sites to use SSL/SNI so I think the issue is related to that.

I’ll post if I find a solution.

Thanks, I look forward to the new version.