Support

We actually do include the X-Bz-Content-Sha1 header in the request we are sending to BackBlaze B2. If we send it and B2 doesn't see it, the only reasonable explanation is that something between the two servers (your server and B2's server) is stripping the header.

That would be the transparent proxy server your host is using for outgoing HTTP/HTTPS connections.

Please contact your host and show them both the error message you are receiving and this reply of mine. Then do tell them that requests to all subdomains of backblazeb2.com and backblaze.com must NOT have any of their HTTP headers stripped or messed with. If their proxy does that the upload will of course fail (it will no longer be a valid request to the BackBlaze B2 API).

The extension of the file name does not matter. We don't take it into account. We always upload the files as binary/octet-stream. It is possible that something on BackBlaze's side is stripping away the headers when they see a ZIP extension. 

I believe this is a bug in B2's API. I can reproduce this locally. However, I see that we DO send all the headers! Here's what I see when I enable full verbosity on cURL when trying to make an upload:

*   Trying 206.190.209.126:443...
* Connected to pod-000-1102-15.backblaze.com (206.190.209.126) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: <SITEROOT>/libraries/src/Http/Transport/cacert.pem
*  CApath: none
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=backblaze.com
*  start date: Apr 28 07:51:02 2022 GMT
*  expire date: Jul 27 07:51:01 2022 GMT
*  subjectAltName: host "pod-000-1102-15.backblaze.com" matched cert's "*.backblaze.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> POST /b2api/v1/b2_upload_file/e416a06d75150c1b5bf90a16/c001_v0001102_t0033 HTTP/1.1
Host: pod-000-1102-15.backblaze.com
Transfer-Encoding: chunked
Accept: application/json
X-Bz-File-Name: test/test.zip
Content-Type: application/octet-stream
Content-Length: 262144
X-Bz-Content-Sha1: 255f3be6505f22e298cdbea7c5f427bc96692919
Authorization: <REDACTED>
Expect: 100-continue

* Mark bundle as not supporting multiuse
< HTTP/1.1 400 
< Cache-Control: max-age=0, no-cache, no-store
< Content-Type: application/json;charset=utf-8
< Content-Length: 91
< Date: Mon, 16 May 2022 06:55:49 GMT
< Connection: close
< 
* Closing connection 0

It returns API Error bad_request: Missing header: Content-Length. Well, the header's there even though their API complains it's missing. The funny thing is that if I try the exact same code, unchanged, with another storage container on B2 which is handled by a different B2 storage pod I don't have this issue. So, clearly, something is wrong on B2's side.

That's all I can do on my end. Maybe try using a different storage engine?