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

Advertisement

rocc-o
Joined:
Posts:
3

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

Hello,
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": https://www.backblaze.com/docs/cloud-storage-upload-files-with-the-native-api

How can I do that?
Thank you so much

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
41,518
Location:
Prague, Czechia

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.

Reply with quote

rocc-o
Joined:
Posts:
3

No problems with uploading, and I’m following this procedure with Cloudflare Transform Rules: https://www.backblaze.com/blog/free-image-hosting-with-cloudflare-transform-rules-and-backblaze-b2/

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: https://www.backblaze.com/docs/cloud-storage-upload-files-with-the-native-api

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

Reply with quote

martin
Site Admin
martin avatar

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.

Reply with quote

rocc-o
Joined:
Posts:
3

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: https://winscp.net/eng/docs/library_example_verify_file_checksum
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.

Reply with quote

Advertisement

Advertisement

You can post new topics in this forum