Of course

Violent agreement 🙂

hehe 👍👍

Not sure of the R2 Prices are exactly finalized yet, but just curious about something: With no egress fees, the cost to serve a 1mb file and a 10gb file would be the exact same? Each one would just be one GET request + the extra costs for storing the data themselves, but other then that, no other surprise fees or stuff that could impact you? The only thing I could think of, is depending on how the worker is set up, with unbound it might cost more due to the worker being alive longer for proxying?

I don't know if you'd classify it as a surprise per se, but if you're fronting R2 with a Worker, the Worker and R2 are billed separately. So for a GET to your Worker that proxies it to R2, you'd use 1 Worker request and 1 R2 Read. That being said, when you are acting as a pure proxy for a response, the unbound billing stops as soon as you hand off the Response object (https://blog.cloudflare.com/workers-optimization-reduces-your-bill/ has more details). However, there's probably some room for optimization there because in this scenario you're paying the cost to retrieve the metadata. We could offer a more optimized (but limited) put/get variant that returned a

Promise<Response>

so that your billing time ends immediately when you issue the `.get`/`.put`.

That makes sense, wanted to make sure I wasn't skipping anything in my logic, thanks for your help

Did you try copying a file over to it? Listing files with rclone works fine for me, but when you try to copy or move a file using rclone, it just complains about the non-implemented x-amz-acl header

NotImplemented: Header 'x-amz-acl' not implemented

I messed around with the config a bit and its ACL options, but wasn't able to get it working. It looks like rclone is just using aws's go sdk which is adding those headers.

I was trying to upload a ~1GB File, so had to use API. I tried a few other options but funnily enough aws's official CLI worked the best for me, just setting it up as normal and using the --endpoint-url option only failed randomly once. Probably was an easier way to do it though, I haven't messed around with s3 much

any news on when people that missed the last round of beta invites could be added?

there should be another round this week (like next 8 days)

you would prolly need to look out for the message

I am, just barely missed the last one

__**ProTip for configuring Logpush to R2**__ When I tried configuring a new Logpush job to Cloudflare R2 today, the API said that my endpoint was returning an error. This is because Cloudflare Logpush uses host-based addressing which is not supported by Cloudflare R2 at the moment. I'll give an example of this. My account tag is

e5f0f929bb59b9d5e1bc9b35e9e3bf00

and I want to push logs to the root folder of a bucket called

cloudflare-logs

. If I just try to create a Logpush job with

cloudflare-logs

as the bucket path and

e5f0f929bb59b9d5e1bc9b35e9e3bf00.r2.cloudflarestorage.com

as the endpoint, the Cloudflare API will report that the endpoint returned a 500 Internal Server Error when it attempts to upload a test object. This is because the Logpush API is actually appending the first part of the bucket path to the endpoint. So it's actually trying to hit

https://cloudflare-logs.e5f0f929bb59b9d5e1bc9b35e9e3bf00.r2.cloudflarestorage.com/

which is not yet supported by Cloudflare R2. Instead, you will have to move your account tag so the bucket path becomes

e5f0f929bb59b9d5e1bc9b35e9e3bf00/cloudflare-logs

and the endpoint becomes just

r2.cloudflarestorage.com

. Then Logpush will correctly hit

https://e5f0f929bb59b9d5e1bc9b35e9e3bf00.r2.cloudflarestorage.com/cloudflare-logs/

and you'll be able to create a Logpush job to Cloudflare R2 without errors. Update: If you create a Logpush job using the API, you can force path-based addressing by including

use-path-style=true

in the destination config.

That's... interesting

Ty for finding that out Albert!

What's the value of the

x-amz-acl

header that's being set?

We went with a very restrictive policy for now of not recognizing headers we don't support. We've had problems where us not understanding a header would cause successful requests even though we're not technically implementing the request properly

But compatibility with existing tools is also extremely important. Let me dig into it on our end but if you can retrieve the acl value from your end that would be equally valuable to see.

I bet you it's

private

If that's the case that should be an easy fix because when we add ACL support in the future, we can just assume everything today is private implicitly.

@Chaika can you try rclone now? I've changed it so that `private`/`bucket-owner-read`/`bucket-owner-full-control` are now all allowed values because there's no difference between bucket owner and object owner. I'm also in the process of pushing a fix where

BINDING.get

for an empty object throws an internal error.

missing bucket logging - is that on the road 🗺 ? didn't see in in the compatibility doc either way

Correct. We don't have that piece yet. I don't know if it'll be a GA thing or a fast-follows.

As always, you do have outs here. You could front R2 with a worker to do the logging.

But we will add native support at some point

yep, that's what i'll do - nice to know its on the radar, having the detail appear in another bucket automatically is nice. the graphql will be cool for summary by bucket ops, but the info in the bucket log is much more granular

and I forget is the more common subdomain-based s3 access eventually planned as well? i.e.

<bucket>.<account>.r2.cloudflarestorage.com/<key>

instead of the current path-style

/<bucket>/<key>

Yes