Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Please post verbose logs of an upload using those other clients.

I do not think it's a matter of proprietary header – for what I've understood on these days by digging in the Internet, but I'm not an expert and I could be wrong. I suspect though it is just a matter of verifying checksum of a remote file against a local file: just the checksum, not the Backblaze proprietary header x-Bz-Content.
I think somehow enabling WinSCP to have the SHA1 checksum set in the file info for the file upload. I've tested this in some other SFTP/FTP clients that have it in their Options - and ETag is no more "unverified". But I like WinSCP better and I'd love to solve this. I've seen something like a script, I presume, in your documentation:
Could this be the solution? If yes, how could I implement such function into WinSCP GUI? You see, I'm not an expert. Thanks in advance, and anyway I will continue using WinSCP for a myriad of other things WinSCP is really useful for. My best regards.

Note that WinSCP hardly knows that even Backblaze exists. So it does not send any proprietary Backblaze headers. It definitely does not send any "do_not_verify" header.
I'll see if more people need these, before implementing any such proprietary headers.

No problems with uploading, and I’m following this procedure with Cloudflare Transform Rules:

Everything works as expected, except that I get in Response Headers ETag: unverified: ... and Cache-Control: max-age=31536000 instead of Cache-Control: public, max-age=31536000 (missing public).
And this is causing some problem with Cloudflare caching.

I've asked to Backblaze support and they told me:

The "Etag: unverfied..." is indeed a reference to the SHA1 checksums of the files. Whatever you have set for WinSCP it is uploading files with the X-Bz-Content-Sha1 header set to "do_not_verify" which we do not recommend. You can read more about it in our documentation page:

Specifying do_not_verify as the checksum and letting B2 compute the checksum of the file. In the case where there has been data corruption and the checksum doesn't match the data sent, the first two options give B2 the opportunity to verify the checksum, and reject the upload without storing anything in B2. With this final option, the file is stored no matter what, and you have to delete it yourself if there is a problem with the checksum.

This is likely what is triggering the other issue in regards to the "cache-control" missing "public"

I would suggest reaching out to WinSCP support in regards to how you can have their upload process include the x-Bz-Content-Sha1 header for the 40-character hex checksum of the file or the string hex_digits_at_end

Re: How to include the X-Bz-Content-Sha1 header in the upload process?

Under what circumstances does Backblaze API require that? I've tested an upload to B2 bucket now using WinSCP 5.21.1 and it works without any problem.

How to include the X-Bz-Content-Sha1 header in the upload process?

I'm uploading images on my Backblaze B2 storage/bucket and I would need the upload process to include the X-Bz-Content-Sha1 header for the 40-character hex checksum of the file or the string hex_digits_at_end.

Backblaze is requesting "SHA1 Checksums - You must always include the X-Bz-Content-Sha1 header with your upload request":

How can I do that?
Thank you so much