Yep: https://developers.cloudflare.com/r2/platform/s3-compatibility/s3-compatibility/

then ShareX support r2 already built in

s3 api bug in `GetObject`: ranges for a single byte should be allowed e.g.

range: bytes=0-0

for the first byte. Range specs are inclusive. Currently there is a validation error that says

range range must be positive

for valid requests like this

also partial responses should have an http response code of 206, not 200

hmm so you can't make r2 assets publicly accessible without a worker? thats a bummer, is that coming in the future?

That it returns an empty list without a limit of 0 is undoubtedly a bug. It’s weird because we do have test coverage over list. I’ll have to see what’s going on.

Does it at least respond with the correct range if it’s

bytes=0-1

?

Yeah, they'd like to implement it one day but they've said they have no timeline.

yep (partial body is correct, first 2 bytes in this case), and the

content-range

in the response is correct (

bytes 0-1/n

), but not the status code (should be 206) and it should allow a single byte range (amazon/other servers do etc)

Any chance you could support

sha256

checksum in

R2PutOptions

along with

md5

and

sha1

? As far as I am aware, the SHA-256 hash is already calculated as part of verifying the signature when the S3-compatible API is used (

x-amz-content-sha256

), so it should just be a matter of checking if the calculated hash matches the client-provided hash.

Does R2 do anything with the

LocationConstraint

included in the payload to

CreateBucket

? It seems to take any value.

also

CreateBucket

does not return the expected

Location

header in a successful response

This value is currently ignored.

Filed a bug to track that.

Hmm, wondering what is meant by "Object Lifecycle" for

PutObject

, is bucket lifecycle config supported?

I think that's a bug in the docs

Object lifecycle isn't supported currently

ok thanks

I have some tweaks for the docs up for review https://github.com/cloudflare/cloudflare-docs/pull/4213. Someone from the docs team needs to approve (this includes the object lifecycle inaccuracy).

btw r2

ListObjectsV2

seems to return owners for each key by default, they are supposed to be elided in v2 by default, and only enabled with

fetch-owner

also docs for

PutObject

should probably list

Content-Type

among the supported headers, since it does appear to be supported by r2

Does anyone experienced

The value cannot be converted because it is not an integer.

error on

R2.put()

? I can't get the underneath stack trace to gather more info It used to work fine, but I started using Worker bindings (request to another worker to get body to store in R2) and now Put fails with such error, but the response from worker binding fetch looks good

Can you share your code? And what's your

compatibility_date

set to in your

wrangler.toml

?

Probably difficult to replicate, as I don't have an isolated test case: https://github.com/nftstorage/nftstorage.link/blob/feat/api-with-worker-bindings/packages/api/src/perma-cache/put.js#L45 (fails in the put call, even without optional params)

compat date is set to 2022-04-17

Yeah and you're using

r2_public_beta_bindings

as a specific compat flag anyway - that was my initial thought, since I saw that error quite a bit with the older internal bindings, but haven't run across it with the new bindings yet

Hopefully someone else has another idea that can help!

oh yes, thanks anyway. Will wait to see if someone else saw it before

Had that error yesterday and the only thing that fixed it was deleting the worker and restarting