700ms doesn't sound unrealistic depending where your R2 bucket is and where your Worker is being invoked - you can hit the

?location

endpoint on the bucket's S3 API to get the region if you're unsure.

I think it might now appear in the dashboard? Not too sure

its in europe but someone from the us had similar results

hello all! i have a n object (html file) in my bucket, and when i visit the link it downloads the html file isntead of showing it, any way to get it to show the file instead of downloading it?

You'll need to set the

Content-Type

of that file to

text/html

so it can be rendered, and not downloaded

Depending on how you uploaded this, it can be set in the metadata at

httpMetadata.contentType

.

ah thank you, i got it working, your a star

Hey all, we've been using R2 to store podcast assets for a few months using r2.dev and it's been working well except recently it stopped syncing. We contacted apple support and apparently they can't reach the XML feed stored on r2.dev. They get a "This site can't be reached" error. Has anyone run into that before?

r2.dev has heavy rate limits and poor caching, you need to set up a custom R2 domain name. r2.dev isn't for production

Got it, thanks!

Hey, I had a doubt is it possible to list objects which were uploaded after a particular date?

There is no way to have the server do it, but you can list all objects and then sort locally, which may or may not be feasible

Alternatively, if you have references to your objects stored in a database or something, use the database to track that information

You could also technically sort by ""date"" if your objects have their date in their key prefix or something

I am actually creating an admin page for internal test builds of our app. I will try with date in the key. Would it be good idea to list objects in the start and refresh every 5min or so?

I would say the truly best idea is to track uploaded files in a database

You could attach literally any other data to them that way

But if the date is part of the key prefix, you can list objects after a certain date directly on the API, you would not need to keep syncing

Because you could use

start-after

doesn't start-after require whole key instead of a prefix? I will try to store references in db since that does seem like the best option. Although making sure it stays consistent with the bucket seems bit extra work. Thanks.

Hi, I am using workers + r2 to implement an API (i dont control the spec) for file uploading. It needs to support the following case - create session - upload part * N - complete upload The obvious solution is to use multipart uploads for this, but the api does not require a 5mb minimum, so when I try to complete the upload with a small file, i get the following error:

completeMultipartUpload: Your proposed upload is smaller than the minimum allowed object size. (10011)

Is there a better way to do this? Or some way to get around the minimum size?

Just use PutObject if your file is too small for multipart

If you must do parts then it also must be big enough for multipart

i dont know beforehand how big it will be. Unless there is a way to get the part data back from uploaded parts, i have to use multipart upload. I am trying to pad it to 5mb (eg something like

await upload.uploadPart(nextPart, new Uint8Array((5 * 1024 * 1024) - totalSize).buffer)

, but always seem to run into the same minimum size error. Is it actually 5mb or am I mistaken?

I can't find any documentation about the min size limit, it was just mentioned here at some point. Is there a doc I am missing?

It is on here in a code comment: > 5MB is the minimum part size, except for the last part But I assume this 5MB minimum size is pretty universal across all S3 compatible providers given that is the limit S3 sets.

Is there any plans to decrease the scope of what R2 API tokens have access to? Currently: * There are two access levels, read, or write, any consideration to make this more granular? What if my token only needs to Put items, but does not need to Delete anything? (protecting from mass deletion attacks) * Allowing us to scope what buckets each token has access to, I host a few R2 buckets, and a lot of them have to write to their relevant R2 bucket, it would be neat if I could scope them to be able to only write to the buckets they actually need.

Bucket scoped is coming soon I believe there was a tweet saying Q3 this year. As far as the first point not sure if that is currently planned.

Great to hear about bucket scoping! Sounds good, is this the best place to leave product feedback for the first point?

Yes it is the team actively monitors this channel