I have a cron job setup on one server to run a backup script in PHP that is hosted on another server.
The command I've been using is
curl -sS http://www.example.com/backup.php
Lately I've been getting this error when the Cron runs:
curl: (52) Empty reply from server
If I go to the link directly in my browser the script runs fine and I get my little backup ZIP file.
In case of SSL connections this may be caused by issue in older versions of nginx server that segfault during curl and Safari requests. This bug was fixed around version 1.10 of nginx but there is still a lot of older versions of nginx on the internet.
For nginx admins: adding ssl_session_cache shared:SSL:1m; to http block should solve the problem.
I'm aware that OP was asking for non-SSL case but since this is the top page in goole for "empty reply from server" issue, I'm leaving the SSL answer here as I was one of many that was banging my head against the wall with this issue.
This can happen if curl is asked to do plain HTTP on a server that does HTTPS.
Example:
$ curl http://google.com:443
curl: (52) Empty reply from server
this error also can happen if the server is processing the data. It usually happens to me when I do post some files to REST API websites that have many entries and take long for the records creation and return
In my case it was server redirection; curl -L solved my problem.
you can try this curl -sS "http://www.example.com/backup.php" by putting your URL into "" that worked for me I don't know the exact reason but I suppose that putting the url into "" completes the request to the server or just completes the header request.
It can happen when server does not respond due to 100% CPU or Memory utilization.
I got this error when I was trying to access sonarqube API and the server was not responding due to full memory utilization
Try this -> Instead of going through cURL, try pinging the site you’re trying to reach with Telnet. The response that your connection attempt returns will be exactly what cURL sees when it tries to connect (but which it unhelpfully obfuscates from you). Now, depending on what what you see here, you might draw one of several conclusions:
You’re attempting to connect to a website that’s a name-based virtual host, meaning it cannot be reached via IP address. Something’s gone wrong with the hostname—you may have mistyped something. Note that using GET instead of POST for parameters will give you a more concrete answer.
The issue may also be tied to the 100-continue header. Try running curl_getinfo($ch, CURLINFO_HTTP_CODE), and check the result.
Curl gives this error when there is no reply from a server, since it is an error for HTTP not to respond anything to a request.
I suspect the problem you have is that there is some piece of network infrastructure, like a firewall or a proxy, between you and the host in question. Getting this to work, therefore, will require you to discuss the issue with the people responsible for that hardware.
In my case (curl 7.47.0), it is because I set the header content-length on curl command manually with a value which is calculated by postman (I used postman to generate curl command parameters and copy them to shell). After I delete header content-length, it works normally.
I've had this problem before. Figured out I had another application using the same port (3000).
Easy way to find this out:
In the terminal, type netstat -a -p TCP -n | grep 3000 (substitute the port you're using for the '3000'). If there is more than one listening, something else is already occupying that port. You should stop that process or change the port for your new process.
I ran into this error sporadically and could not understand. Googling did not help.
I finally found out. I run a couple of docker containers, among them NGINX and Apache. The command at hand addresses a specific container, running Apache. As it turned out, I also have a cron job doing some heavy lifting at times running on the same container. Depending on the load this cron job puts on this container, it was not able to answer my command in a timely manner, resulting in error 52 empty reply from server or even 502 Bad Gateway.
I discovered and verified this by plain curl when I noticed that the process I investigated took less than 2 seconds and all of a sudden I got a 52 error and then a 502 error and then again less than 2 seconds - so it was definitely not my code which was unchanged. Using ps aux within the container I saw the other process running and understood.
Actually, I was bothered by 502 Bad Gateway from NGINX with long running jobs and could not fix it with the appropriate parameters, so I finally gave up and switched these things to Apache. That's why I was puzzled even more about these errors.
The remedy is simple. I just fired up some more instances of this container with docker service scale and that was it. docker load balances on its own.
Well, there is more to this as another example showed. This time I did some repetitious jobs.
I found out that after some time I ran out of memory used by PHP which cannot be reclaimed, so the process died.
Why? Having more than a dozen containers on a 8GB RAM machine, I initially thought it would be a good idea to limit RAM usage on PHP containers to 50MB.
Stupid! I forgot about it, but swarmpit gave me a hint. I call ini_set("memory_limit",-1); in the constructor of my class, but that only went as far as those 50MB.
So I removed those restrictions from my compose file. Now those containers may use up to 8GB. The process runs with Apache for hours now and it looks like the problem is solved, memory usage rising to well beyond 100MB.
Another caveat: To easily get and read debug messages, I started said process in Opera under Windows. That is fine with errors appearing soon.
However, if the last one is cared for, quite naturally the process runs and runs and memory usage in the browser builds up, eventually making my local machine unusable. So if that happens, kill this tab and the process keeps running fine.
Another common reason for an empty reply is timeout. Check all the hops from where the cron job is running from to your PHP/target server. There's probably a device/server/nginx/LB/proxy somewhere along the line that terminates the request earlier than you expected, resulting in an empty response.
In my case this was caused by a PHP APC problem. First place to look would be the Apache error logs (if you are using Apache).
Hope this helps somebody.
It happens when you are trying to access secure Website like Https.
I hope you missed 's'
Try Changing URL to curl -sS -u "username:password" https://www.example.com/backup.php
My case was due to SSL certificate expiration
In my case I was using uwsgi, added the property http-timeout for more then 60 seconds but it was not working because of some extra space and config file was not getting loaded properly.
Source: Stackoverflow.com