A small release today with some fixes to ranges: S3 GetObject ranges are now inclusive (bytes=0-0 correctly returns the first byte) S3 GetObject partial reads return a 206 "Partial Content" response

If it's helpful, I put up a Gist that shows a fully-formed working public beta bindings example: https://gist.github.com/vlovich/b02d3242e534e579e554366ad0cb2a3d

$ cat wrangler.toml 
name = "demo-r2"
compatibility_date = "2022-03-13"
account_id = "...."
usage_model = "unbound"
workers_dev = true
main = "src/index.ts"

[[r2_buckets]]
binding = 'BUCKET'
bucket_name = 'my-bucket'

That's the weird part to me. I would expect the interaction to not count as class A or B when using R2 with Worker since the operation remains on Cloudflare internals and you already pay for Worker time.

Still waiting patiently for a way to bind R2 without workers and just let it serve static files publicly.

The mental model I have is that for R2 you're paying for the I/O request and for normal Workers you're paying for the RAM/CPU. That's why Workers have a single request cost whereas with R2 it's bifurcated based on the kind of operation you're doing. I think this is consistent with other providers. E.g. if you front with AWS VM or AWS lambda you're still going to be paying for the cost of the VM/edge function AND for the S3 request. Amazon only gives you a break and 0-rates the egress fees of S3 in that case. With R2 egress is always free so....

@James R2 in workers runtime doesnt error when the file doesnt exist anymore now, so you can probably safely remove the try/catch from your sharex worker

I removed it in mine and just left the null check and it works good now

oh perfect, thank you! Will update the repo shortly 🙂

Umm.... we're actually debating what should happen here right now

Here's the design problem we have right now

🤔

const object = await R2.get('key does not exist')

vs

const object = await R2.get('key does exist', { onlyIf: { etagMatches: "abc" } })

In both cases

object

ends up

null

...

Or to make that even clearer:

const object = await R2.get('key does not exist', { onlyIf: { etagMatches: "abc" } })

I'm wondering if the

onlyIf

should return a different kind of object maybe.

I would (personally) expect to get

null

if the obejct doesnt exist and some kind of error object if it does exist but the etag doesnt match

But then you could also argue "Well why not just have an error obejct for the not found as well" and ugh

Unfortunately I'm in a design corner there. I can't throw a structured error. Just a generic

Error

with an error message

What would be the usecase for using

onlyIf: { etagMatches

compared to getting the R2 object and then checking its etag yourself?

Hmm....

The main thing is that the

body

isn't retrieved and it's faster. But maybe then we return

R2Object | R2ObjectBody | null

I had (naively) assumed that the body wouldnt be retrieved unless you use it somewhere, but I'm also not really aware of how R2 objects work in general

Because I like the idea of it returning an object or null, and then you check the objects data and use the body when youre ready

There's not a separate fetch that happens when you access the body

Yeah thats fair

You're getting an HTTP response

What would this

R2Object | R2ObjectBody | null

idea entail/solve?

In a precondition failure scenario you'd get back the object but there wouldn't be a

body

Ah I see, thats a pretty good compromise yeah

Then you can do null checks on the object and the body separately depending on what you're trying to do

This is consistent with the call. I like that.