Support » Fixing WordPress » Site Health Status

  • Darshan petkar

    (@imdarshanpetkar)


    I am getting an error of
    Your site could not complete a loopback request!

    Loopback requests are used to run scheduled events and are also used by the built-in editors for themes and plugins to verify code stability.

    The loopback request to your site failed, this means features relying on them are not currently working as expected.
    Error: cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received (http_request_failed)

    What should I do now?

Viewing 8 replies - 1 through 8 (of 8 total)
  • Moderator t-p

    (@t-p)

    Ask your host why loopback is failing.

    I am running a test site locally, the “Site Health Status” reports “Your site could not complete a loopback request…
    Well, my understanding of a loopback request succeeding, in the PHP WordPress context, is if a PHP script running on the site’s server makes an http(s) request from the server site, for a server site resource, it will be satisfied.
    In examining the “function can_perform_loopback()” in “class-wp-site-health.php”, for the function’s action the URL is the “admin_url()”, for example “https://mysite/wp-admin/”. This will invoke the admin’s index.php and as a consequence the result is “Error: cURL error 28: Operation timed out after 10005 milliseconds with 0 bytes received (http_request_failed)”!
    My wp-admin folder contains a text file “crash.txt” and when I modified the URL in the code to for example “https://mysite/wp-admin/crash.txt” the loopback request succeeded.
    Similarly, I created a PHP script which I added to the site, which used curl to request “https://mysite/” which invokes the site’s index.php resulting in “cURL error 28”, using a test index.html in the request e.g. “https://mysite/ index.html” the request succeeded.
    So, it feels like the real issue is that the timeout may be due to the “index.php” files are getting into some kind of loop, as it seems to me that loopback requests work, and there’s not an issue with a firewall or the network or something else.
    Further the REST api failed with “cURL error 28” and I suspect this is related.
    Any insight into this?

    • This reply was modified 1 month, 1 week ago by tezzerfx.
    • This reply was modified 1 month, 1 week ago by tezzerfx.

    This is an addendum to the prior post, namely that it seems the timeout occurs for for any loopback request where the resource is a PHP script e.g. “https://mysite/ anyscript.php”. Any suggestions would be appreciated…

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    Look through your theme and plugin files for any reference to session_start()

    If you find it, that is likely your problem.

    WordPress itself doesn’t use PHP sessions, in any way. But if you have a plugin or theme which does, and it starts a session indiscriminately, meaning that it tries to start the session every time without checking to see if a session is really needed, then you can run into this problem.

    Basically, when the code starts the session, then it uses the particulars of the connection to lock the session file for modification. When the request is done, the session becomes unlocked. Now, the loopback checker needs to check that the same user that you are currently logged in as can access the site via loopback. So it’s making that request with all the same information as you. Which means that if a session_start is called, it’s doing to get the same session.

    But, since this is a loopback request, then if the session is already locked, then the second request will try to get the same session, and it will be blocked. This is a lock state. You have the requesting process holding the session, and it’s making a request that is causing another process to wait for that session to be freed up. So it times out after 10 seconds. And thus, this problem.

    The solution: Avoid using PHP sessions. They’re unreliable or incorrectly configured on a lot of hosting systems to begin with, which is one reason WordPress does not use them. And if you do use sessions, then don’t start them unnecessarily. Having every single hit lock a session even when it doesn’t need to is just bad programming anyway, you only start the session if it is actually needed, and it almost certainly is not needed to just, for example, load the admin screen up.

    Thanks Otto for the swift response. After further digging and testing, and please note that my test WordPress used to check loopbacks has no plugins enabled with the default 2020 theme, but that’s an aside, it seems the issue has nothing to do with WordPress. It’s purely a PHP to PHP loopback request problem. If 2 PHP scripts, script1 and script2, are on the sever with FastCGI enabled, where script1 requests via cUrl script2, scipt2 can not be requested because the FastCGI connection is blocked by script1 waiting for the request response, after scipt1’s timeout expires, the request for script2 succeeds, but it’s too late for the output data to be retrieved but script1, which died! PHP-FPM via PHP isn’t available on windows, so it seems only a load balancing FastCGI proxy server for multiple instances of php-cgi.exes or some clever protocol in the server to achieve the same thing is needed. Until then WordPress PHP to PHP loopbacks are doomed!

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    If 2 PHP scripts, script1 and script2, are on the sever with FastCGI enabled, where script1 requests via cUrl script2, scipt2 can not be requested because the FastCGI connection is blocked by script1 waiting for the request response,

    Check the php.ini file for session.auto_start and see if that is enabled. Just in case. Or check the phpinfo() for same.

    tezzerfx

    (@tezzerfx)

    Check the php.ini file for session.auto_start and see if that is enabled.

    It’s not enabled and it’s the same result if it is enabled. With lighttpd as the web server I can run 2 instances instances of php-cgi.exe and load balance between them as a round robin, which I did and that enables the loopback to succeed. With jetty which I prefer to use, the fastcgi is implemented via a custom FastCGI Proxy Servlet, request processing is asynchronous, but the I/O is blocking, and so far I haven’t found a way to run multiple load balanced instances of php-cgi.exe in jetty. Under windows php-cgi can’t spawn sub-processes that can handle concurrent connections. It seems the lighttpd solution in some form is required.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    Ahh, well, webserver configurations are neither here nor there, I suppose. It works fine with Apache and the PHP module DLLs on Windows, but that’s all the experience I have on Windows HTTP servers. On Linux systems I usually prefer nginx.

    But yes, you will need to be able to run more than one PHP process at a time.

Viewing 8 replies - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.