Support

Please note that the following reply is not arbitrary. We have worked with another user who has the same issue and have already confirmed that the problem is not on our or Google's side but with the hosting service you are using.

It would appear that you have a transparent proxy server, cache or firewall in front of your server which blocks HTTP PUT requests. The Google Drive API requires that we use PUT requests to perform a multipart upload of files over 5MB. Therefore due to no fault of ours or Google Drive's it is impossible to upload backup archive files over 5MB to Google Drive from your server.

You need to contact your host and ask them to resolve this issue. There is nothing you, us or Google can do about it -- it is a problem with the setup of your server which is controlled by your host.

In the meantime you can either use a different upload service whose API does not require using HTTP PUT (such as Dropbox) or set the Part Size for Split Archives to 5MB. The latter is not a very convenient option. It will cause your backup to be split into multiple files, each one up to 5MB. This means that a 200MB backup results in 40 backup archive files.

I already explained why I cannot help you: because the problem DOES NOT come from our code. So, let me reiterate.

The issue cannot be reproduced. More specifically, I've had another client with the same issue. It kept happening on their server. When I used their Google Drive credentials on my development server everything worked fine. So it's very clear to me that the problem lies with the host.

Moreover, I did more tests on the affected server. Dropbox worked. Google Drive didn't. I dove right into the gritty details and found WHY it doesn't work. The Google Drive API, unlike Dropbox, uses HTTP PUT requests (Dropbox, S3 and others only use HTTP GET and POST requests). As soon as a PUT request was sent we got an immediate (sub-millisecond) error reply. This means that something is ON or NEAR the server that blocks HTTP PUT requests. You cannot travel faster than the speed of light and the speed of the response puts the culprit within 150Km of your server. So I reasonably have to assume that the problem occurs within your host's infrastructure or the data centre they are leasing space from.

Moreover, receiving an HTML page with the HTTP error is NOT what Google does. So we know that this issue is not coming from Google. We also know that this does not come from our code for the simple reason that our software is receiving that response from somewhere outside it. We know that this response cannot be modified by anything running inside Joomla for the same reason.

So the culprit lies squarely between your web server and Google's server. Since this cannot be reproduced except in a very small minority of servers it would appear that the problem is somewhere in your server, your host's infrastructure and the infrastructure of the data centre they are leasing space from. I am not your host and I have nothing to do with their data centres. So I cannot help you. It's objectively out of my hands.

So, if you need my urgent help here is what to do: EITHER use a different storage method (e.g. Dropbox or Amazon S3) OR move to a different host that actually works. I cannot change your host's broken infrastructure and I cannot tell Google to stop requiring PUT requests to create new files. I am not your host, I am not Google, I am not God.

Since this is an issue outside of our code and not under our control I am invoking the Terms of Service's Support Policy to which you explicitly agreed to when subscribing. Per the TOS I am closing this issue since we have already confirmed that this issue is unrelated to our code and we have pointed you to the right direction.

Further information: the problem seems to be that the host is stripping or corrupting the HTTP Authentication header from HTTP PUT requests sent to remote servers through PHP's cURL module. This does not happens with POST or GET requests. You can ask the host to check if something went wrong with their libcurl when they updated PHP to 7.2.11 last week.

I am reopening the ticket since that might actually result to a more sensible response from the host.

Hello,

I am sending this reply to all users who have filed tickets regarding errors uploading to Google Drive since November 7th. All of you have reported that you suddenly started receiving the error

Invalid JSON data received: <HTML> \n <HEAD> \n <TITLE>Not Implemented</TITLE> \n </HEAD> \n <BODY BGCOLOR="#FFFFFF" TEXT="#000000"> \n <H1>Not Implemented</H1> \n <H2>Error 501</H2> \n </BODY> \n </HTML> \n

and uploading to Google Drive failed.

In most cases I have already told you that this is a hosting error. Some of you did try to contact your hosts but they either refused that this is an error with their infrastructure or deflected and said that the error is on our side. This is partly because my original hunch that this is a firewall or proxy in front of your server was misleading, partly because they didn't bother pursuing this issue further.

One of the affected hosts did take the time to troubleshoot this issue and found out that my second hunch (broken cURL library) was actually the culprit. It appears that a recent update to the cURL library, used by PHP to contact remote servers, has a weird bug which prevents it from correctly identifying the HTTP protocol version the remote server speaks. Instead of using HTTP/1.1 it falls back to HTTP/1.0. However, Google Drive's API servers do NOT speak HTTP/1.1 and return the HTTP 501 Not Implemented error. To make things even weirder, this bug only happens with certain PHP verbs. As I already told you, HTTP GET and POST requests work fine, PUT does not. This is the reason.

Following that lead we have created a developer's release with a workaround to this cURL bug. We are explicitly telling cURL to use HTTP/1.1 when contacting Google's servers. Since we cannot reproduce this issue on any of our development or live servers we would like to ask you to install this developer's release and use it to perform a backup that uploads to Google Drive, then tell us if it resolved the issues you were experiencing. The developer's release is identical to the already published stable plus the fix.

You can download the developer release from:

• Akeeba Backup for Joomla!: https://www.akeebabackup.com/download/developer-releases/akeebapro/rev8ff0d814.html
• Akeeba Backup for WordPress: https://www.akeebabackup.com/download/developer-releases/backupwp-dev/rev52043ca9.html
• Akeeba Solo: https://www.akeebabackup.com/download/developer-releases/solo-standalone-dev/rev52043ca9.html

After installing the developer release you will see that an update is available. Please do not update! This will downgrade you back to the previous stable.

Thank you in advance for your co-operation.