but finally managing to successfully upload was so satisfying 😛

So much that! 🙂

i was so worried that amazon gonna release new signatures every year and waste my time implementing them

luckily they stopped at v4

Not really, we determined later in the conversation that it was because R2 was requiring the signature line to be separated with spaces as well as commas (

", "

) and that was raised to stop being the case for R2 soon™️ so then it will work with ShareX S3 support

I got it working by modifying the ShareX code to have a space there, but it soon won't be necessary

Your code works with basically every other provider so I'm pretty sure it was just R2 being early and doing funny things

because i'm also using amazon s3 as my default destination, it is important for me for that destination codes to be flawless

Sorry. The sigv4 expert pointed out a flaw at my initial attempt at a hack so I spent today writing a proper fix. I was in the office today test driving the hybrid thing and wasn't quite as efficient as I would have been from home. I did manage to finish off a more robust cleanup of our code rather than the one-off hack I proposed yesterday & have working tests too. Once the next round of reviews is complete should be good to go. @Jaex I'll double-check tomorrow with Greg if we can get you onboarded.

thanks for letting me know

The rule of thumb is that software that works with AWS S3 should work unmodified with R2 using the S3 compatibility endpoint (barring the application making assumptions based on implementation details of S3 that aren't actually guaranteed in the spec). In other words we intend our S3 API to be a strict superset of AWS (modulo unimplemented features) so where there's a difference it's probably a bug. We have layered in extensions (e.g.

MERGE

for the copy directive or supporting unicode metadata values via rfc2047 encoding) but those are intended to be layered in in a non-conflicting way (i.e. you have to opt into using them)

I got no response from Greg 😞

trying to GET an object using

@aws-sdk/client-s3

, however i get

NoSuchBucket: The specified bucket does not exist.

error whenever i try to do so. i use

<BUCKET_NAME>.<ACCOUNT_ID>.r2.cloudflarestorage.com

as the Bucket entry

Can somebody help me remember how one does the Secret Key thing with the API Token value? If I have the API Token

VMMCiqJIEWjnE6RhzMaSJtk8PDjeTON7k4tAdB0M

(already rolled, no longer valid 😛), what should I do...? Got the ID from the dev tools.

And then it’s the ID of the token in the JSON you get at the tokens endpoint?

Yup!

And path-style, not vhost?

yeah, only path style is supported for now

Gonna try with the ShareX equivalent for Mac which is Dropshare… we’ll see if it works ahah

Thanks, @albert!

Only path-style addressing is currently supported. So you should be using

<ACCOUNT_ID>.r2.cloudflarestorage.com/<bucket name>

> (can't find these headers with Browser search until you expand it) https://developer.chrome.com/blog/hidden-until-found/ > The

hidden=until-found

HTML attribute and

beforematch

event can solve these problems. By adding

hidden=until-found

to the container for your hidden content, you make it possible for the browser to search text in that hidden region, and reveal the section if a match is found. Seems like it will be possible in the near future with Chrome, and Firefox also has it on their radar to add support for this ( https://bugzilla.mozilla.org/show_bug.cgi?id=1761043 )

Good tip. Do you know if this will apply to the built-in

<details>

tag without needing Javascript to hide/expand?

Put up a proposed wording fix here: https://github.com/cloudflare/cloudflare-docs/pull/4255

Dropshare uses the

x-amz-acl

header and the return, as some saw already above, is a 501 not implemented...

I'm pretty sure I fixed that already. Values of `private`/`bucket-owner-read`/and

bucket-owner-full-control

are allowed as they don't require any state to be recorded on our end (all these permissions are currently implicitly the same within R2.

Fix should have gone out April 23 around 17:15 UTC (10:15 am PDT)

Please let me know if that's not the case