Support

HTTP 413 comes from outside our code and means Payload Too Large: https://developer.mozilla.org/en-US/docs/web/http/status/413

Now, here is the thing. As you said, Amazon's limits are far bigger than that. On top of that, Amazon does not return an HTTP 413, ever. It has its own error code reporting through the XML response it sends back.

I am pretty sure that your host has a proxy sitting between your server and the Internet. Most likely it's SQUID set up as a transparent proxy and there's a bit of iptables magic to make it truly transparent (as in: any request to an Internet resource over TCP ports 80 and 443 automatically goes through SQUID, very simple to do once someone has pointed out how it's done). Indeed, SQUID will return an HTTP 403 when the request body exceeds a preset threshold, see https://community.sophos.com/utm-firewall/f/management-networking-logging-and-reporting/31375/http-1-0-413-request-entity-too-large. I have actually tried that configuration on an Ubuntu box and yes, I do get the same result you do (I set the limit to 5Mb as I didn't want to die of old age waiting for a 200Mb backup to happen). I also happen to know that this SQUID setup is definitely and for a fact how many commercial hosts configure their servers. That's what makes me pretty sure that this is what is going on in your case.

There are two ways to deal with your host's restriction.

Easy and recommended method: uncheck the “Disable multipart uploads” option in your profiles' Configuration, Post-processing Engine, Configure pane. This will upload the barckup archive in small chunks. Each chunk is up to 10Mb big so you never get to hit the limit on your server. This also allows spreading the upload between multiple page loads, making it far less likely that it will time out.

Virtually impossible method: Try to convince your host that they need to remove the HTTP request body limits in SQUID. Unless you are on a dedicated or managed server this would be a no-go.

Yes, it tells me that the host is messing with the request headers. Most likely they are caching the request we send to Amazon S3.

The way the upload works is this. We take a chunk of the backup archive. We calculate its size and its MD5 sum. We combine this information with the current date and time, your Amazon access, the region, the bucket name and the path of the file in the S3 bucket (in a certain order, prescribed by Amazon) using the HMAC-SHA-256 algorithm using the Amazon secret key as the password. The result is the signature which is sent in the HTTP authorisation header to Amazon S3. Amazon S3 does the same process and compares the signature it calculates to the one we send. If there is a difference it throws the error you are receiving.

Since a whole file is uploaded just fine it means that the inividual components are calculated correctly, including the current date and time (Amazon allows a maximum of ±15 minutes to the actual time the request was sent). The fact that a smaller request fails immediately tells me that your host has cached the request and does not send to Amazon the HTTP headers we calculated and asked to be sent. Therefore the request fails.

Unfortunately, you wil have to contact your host and tell them to fix their broken caching.