Support

You need to contact your host. This message means that your site tries to access the URL (with the dlid), but PHP gets no response back. Since you've already established the URL works, the only reasonable conclusion is that something on your host's side is blocking the response.

I can tell you that in pretty much every case like this the problem has been a misconfigured transparent HTTP proxy used by the host. 

Transparent HTTP proxies automatically handle all HTTP requests made by anything running on the server – including your site, and its core or extensions update code. From the host's point of view it makes sense. Most of these HTTP requests are duplicated across several sites. It makes no sense doing the same request over, and over, and paying for the bandwidth to do so when you can cache their results and deliver them faster. However, a misconfiguration of this transparent proxy may result in some circumstances in the proxy caching the wrong data, or no data at all. For example, if the caching does not take into account request parameters, if POST requests are cached, or if requests with an HTTP status other than 2xx are cached (all of which violate the RFCs governing how proxies should work) you end up with invalid or no data cached. On top of that, it is possible that the proxy fails outright to provide a response back to the initiating programme (PHP in this case). This is not idle speculation. I have both troubleshoot these issues, and reproduced them in the lab (using Squid Proxy enforced transparently with iptables, like many hosts do – this method also works with Varnish and other caches). The good news is that the host can easily fix that once you tell them what your problem is.

The XML file is the update information, hosted on Amazon CloudFront CDN. We already know that you can load that; that's why you can see the update to begin with.

The XML update information file, however, IS NOT the update package. It points to the update package which, as you already know, is a different URL on our site which is behind CloudFlare CDN. This is important for them to know, as it has implications about DNS resolution which might be important depending on their server configuration.

I would recommend asking them to escalate the issue to someone who actually knows what they are doing.

And since you're wondering if you can trust me over your host, yes, you can. I wrote the code in Joomla which retrieves the update package, back in 2012. I have troubleshot these connectivity issues very thoroughly over the years. In my previous reply I even told you how I've simulated this exact failure mode in a lab setting. In case the significance of that escapes you: this requires troubleshooting the issue, identifying the problem, understanding it to minute detail, and only then can you create a configuration to reproduce it. I've been doing server management for over two decades, and maintaining our backup software –which requires a deep understanding of server internals to pull off– the last 18 years. I will also tell you that my expertise is contained within the host/VM; I don't do network routing, VM migration, etc. But that's okay, because I don't run a hosting service, I am here to help with the application and that only requires me to be an expert in the application and its execution environment up to and including the server (host) environment everything runs in. I hope that helps you understand better where I come from and why I know what I'm talking about.

No, no, no offense taken! I just wanted to clarify who I am because I don't think I am anywhere near as important for people to magically know who I am and what I spend my time on – and that's perfectly okay. If you know who I am, no problem, you already had all the info to make an informed decision, ignore the last paragraph of my previous reply :)

First of all, make sure that Joomla! does indeed see the correct version being available: 9.9.9. If you see a different version, go to System, Update, Extensions and click on Check For Updates.

If you do see version 9.9.9 and get the error you mentioned, note that it comes from the file libraries/src/Http/Transport/CurlTransport.php line 177. This happens when the PHP cURL extension's curl_exec() function returns an empty string, but it does not report any error message through curl_error().

Why could that be, when they can fetch the URL from the same server with wget? Well, there are a few differences.

First of all, have you accidentally set up a proxy on your site (System, Global Configuration, Server, Enable Outbound Proxy), or maybe need to set one up but have not? It's easy to check if you have set one up, and the host can tell you if you should set one up (and what the settings would be).

The second difference is the timeout. Since Joomla! runs on the web it sets a limited timeout during which the entire file needs to be downloaded. It is hard-coded to 20 seconds. When the host downloaded the file, did they time the time it took? If it took more than 20 seconds, there's your problem.

The third difference si taht Joomla! uses a special User-Agent string (Joomla). While this is a valid User-Agent as per RFC 7231 §5.5.3, it is unusual in that it has no version part, i.e. it's NOT something like Joomla/1.2.3. We DO allow that on OUR server, but transparent proxies might choke at this kind of valid but unusual User-Agent strings. It's rare, I've seen it though, so I ought to discuss it.

Finally, here's a bit of esoteric knowledge which might be the key. Joomla! sends the HTTP header Expect: header for all requests, not just POST, but also GET. This might be very relevant indeed, because the purpose of this header is to tell the server to send an HTTP 100 Continue with an empty response body before continuing processing the request. However, this could lead to a proxy server seeing the HTTP 100 Continue response and return that as-is ignoring the rest of the request. This would indeed result in Joomla! receiving an empty message body, with an HTTP header that's NOT a redirection or error code. This would indeed cause the condition in line 170 to be true, and the condition in line 173 to be true as well, leading to the perplexing message from line 175. Of course the problem is not really in Joomla! itself, but the fact that a proxy cocked up and treated an HTTP 100 Continue as the final response to be forwarded to the client. If I recall correctly, Squid does that, even though it's not supposed to. We've seen that a few times with some third party remote storage services which rely on HTTP 1xx messages to convey status during file upload. This is not the kind of situation I would expect any host technician to troubleshoot themselves.

Are they sure they know what they are doing? What on Earth would the .htaccess ON YOUR SITE have to do with a request made to a completely different site?!

I know exactly what the problem is, and they should've caught it before deploying this PHP version. Hint for them: different PHP versions are linked against different libcurl versions, of which the support tech tested none.

Unfortunately, this leaves us with only one possible recommendation for you: Move your site to a competent host.

Then they can tell us exactly how they step-debugged Joomla's code and why the download from Joomla! fails. Because, according to what they said, it's not a problem with our server, it's not a problem with their server, so it would have to be a problem with Joomla – which they also now say it's not.