Sitehealth cURL error 28

Hi,

I’m having the same issue, and I think I’ve identified part of the problem (although not the solution, unfortunately.)

derrickr’s excellent comment here explains it well: https://wordpress.org/support/topic/the-loopback-request-to-your-site-failed-4/page/2/#post-10662220

I then searched the plugin code and found a session_start() without a session_write_close(). It’s in Plugin.php at line 158. I tried adding the 'read_and_close' => true parameter suggested here and here, and suddenly all the errors disappeared on the Site Health page, and loopback requests magically work again. But the problem is, now the plugin doesn’t work :/ So obviously that’s not the proper solution, but I wanted to mention it here in case it’s helpful to you.

Also, there is another session_start() in Session.php at line 25, but this one doesn’t seem to be problematic, probably because it’s followed by register_shutdown_function('session_write_close'); // force saving session data if session handler is overridden.

I also spotted the following comments which seem relevant. They seem to be suggesting the use of File storage instead of Session, but I’m not entirely sure how to do that.

* Set storage for postponed response data. Storage\Session is used by default, but if you have problems with overridden session handler you should use another one. (source)

* File storage for postponed response data. Use it if session handler in your project is overridden. (source)

Hope this is at least somewhat helpful. A solution would be much appreciated! This plugin is awesome and I’d love to be able to keep using it. Thanks!

Hey @nekojira thanks so much for the quick response! I understand about not being able to change certain things, and thank you for logging an issue in the github repo.

I have been seeing some related symptoms elsewhere on the site. For example my WP-Cron Events page showed this error and I’ve also received error messages like this one when trying to trigger an import job with cron.

But I’ve been playing with it a bit more and I think I may have found a solution, albeit kind of a hacky one. It looks like there is an option to use a file to store the postponed response data instead of writing it back to the session. And then we can close the session which allows the loopback to complete. And the plugin still seems to work 🙂

Here are the specific changes I made:

I changed line 91 of Connector.php from this:
self::$postponeStorage = new Storage\Session();
to this:
self::$postponeStorage = new Storage\File('/home/path/to/my/textfile');
(where textfile is a writeable text file)

And then I changed line 158 of Plugin.php from this:
@session_start();
to this:

@session_start([
    'read_and_close' => true,
]);

I’m sure there’s a better way to do it but this seems to do the trick for now. Do you think it’s possible that the plugin could support file storage instead of session storage in the future? From what I read in this thread, it sounds like WP core is getting stricter about forcing plugins to not use session.

Thanks!