The bucket should have been created nearby then. Do you see long access times for any other objects?
The bucket should have been created nearby then. Do you see long access times for any other objects? Is it consistently slow?
AI think I selected APAC in the location hint
IIs that near where you are?
AYes, I don’t have many files as I have just started, but same result on at least 10 different files
IAre you using a custom domain or the r2.dev domain?
AI guess, I am in Pakistan and it is in Asia, so it should be
ACustom domain
AI think the response times are fast when cache is HIT
IInteresting. That's expected but still shouldn't be that slow on a MISS.
ICan you try creating a new bucket, not specifying a location hint (leave the field blank so it auto-selects) and then check the response time on that?
IIt's possible that R2 just doesn't have much a presence in Pakistan and so response times are slow, but would be good to confirm that by checking another bucket that doesn't have a location hint selected.
AOk let me try.
I faced similar issue with another CDN service, in case of cache MISS it went on to fetch file from origin which is in Germany. The issue started around 5 days back and their support told me that there is some cable cut issue between Hong Kong and Europe that is resulting in slow downloads. So, I started testing CF
I faced similar issue with another CDN service, in case of cache MISS it went on to fetch file from origin which is in Germany. The issue started around 5 days back and their support told me that there is some cable cut issue between Hong Kong and Europe that is resulting in slow downloads. So, I started testing CF
AI think even if CF doesn't have server in Pakistan. It shouldn't take 15 seconds to fetch a file of few hundred kilobytes anywhere in the world.
ABTW CF has 3 servers in Pakistan. Also in the same city from where I am accessing. Not sure if those servers have R2.
ICloudflare doesn't publicize it's server info (only location info), so not sure where you're getting that info from - but yes, they do have servers in Pakistan. Just not sure they have R2.
A
IOh, makes sense. Those are locations so they may have multiple servers in each one but regardless, R2 isn't directly related to Cloudflare locations.
ISome locations will have R2 and some won't and Cloudflare doesn't make which ones public.
ADoes R2 store data only in one location or does it replicate across servers?
IOne location. Probably replicated across servers for redundancy but in one region, I believe.
ADo you have any information on this? Could this be the reason?
IPossibly? I don't know where R2 stores data for APAC, an R2 employee might have to investigate once the weekend is over.
IIf you're on a Pro plan or higher you could also try opening a ticket.
AOkay. Thank you so much for your assistance.
Enot at the moment
OHi everyone, I am trying to build a production ready application which serves the same image, uploaded to r2, to thousands of customers. We are a little bit skeptical on how r2 provides free egress, especially since in our case, the download rate will be thousands of times higher than the storage space occupied
EYou can, there's just no guarantees about it working or staying the same since its undocumented
KYes, it’s really free egress. Make sure that you add a custom domain to your bucket and configure Cache Rules for it to take full advantage of the cache too
CI'm experiencing a bug when attaching a domain to an R2 bucket, which may be specific to specificly related to Punycode/IDN (Internationalized Domain Names).
The DNS records are successfully added and the TLS cert and https endpoint are initialized, but the website serves Error 1014. Additionally, an error message is shown when trying to "reconnect" the R2 custom domain using the "..." menu. Lastly, the DNS entries are not deleted (and the UI provides no options to delete if we delete the R2 custom domain, as shown by orphaned DNS entry
The DNS records are successfully added and the TLS cert and https endpoint are initialized, but the website serves Error 1014. Additionally, an error message is shown when trying to "reconnect" the R2 custom domain using the "..." menu. Lastly, the DNS entries are not deleted (and the UI provides no options to delete if we delete the R2 custom domain, as shown by orphaned DNS entry
bin.føø.com (bin.xn--f-5gaa.com)R2_domain_added142.95KB
f.com_HTTPS190.41KB
Ohi guys, is there an easy way to serve r2 content through a cdn ?
HJust add a custom domain
OThanks
D'#' is a special character for URLs (fragment identifier), so I suspect it has something to do with that. In a normal HTTP request, anything after the # is not sent as part of the underlying HTTP request. That being said, it does look like it's possibly a bug in R2. If I have a filename of
A user could probably upload a carefullly crafted filename to overwrite other filenames. Although if you are allowing users to upload direct to R2 with filenames they choose, they could probably overwrite other files anyway.
If it's user generated content, you really don't want to be uploading them to R2 willy-nilly with the filename users uploaded it as anyway.
somefile#123.jpgsomefileA user could probably upload a carefullly crafted filename to overwrite other filenames. Although if you are allowing users to upload direct to R2 with filenames they choose, they could probably overwrite other files anyway.
If it's user generated content, you really don't want to be uploading them to R2 willy-nilly with the filename users uploaded it as anyway.
DYep... I uploaded a file via the dashboard as a test... 
somefile#123.jpgsomefile#Seems so... it's how browsers handle requests with
##Or maybe you just need to URL encode object keys when uploading?
DBut even if you are supposed to that, the normal R2 dashboard isn't doing it, so... 
DYou might want to try URL encoding it... Looking at the underlying mechanism for uploading an object, the object key is part of the S3 endpoint... so underneath it all, you are sending the request to:
So I bet that's the culprit right there... the "filename" being part of the request. And anything after the
It might be as simple as URL encoding the filename.
PUT https://{account_id}.r2.cloudflarestorage.com/{bucketname}/{object_key}So I bet that's the culprit right there... the "filename" being part of the request. And anything after the
#It might be as simple as URL encoding the filename.
D...if that's the case maybe it's just a bug in Cloudflare's dashboard and they need to be URL encoding it themselves too (and they are not).
DIt's not an "official" endpoint, but you can create buckets with Cloudflare API without using S3 API.
That can change at any time though, and doesn't solve your problem of improperly signed S3 requests. So uploading objects and other operations are going to also fail.
public function createR2Bucket($accountId, $bucketName)
{
$params = [
'name' => $bucketName,
];
return $this->makeRequest('POST', sprintf('accounts/%s/r2/buckets', $accountId), ['json' => $params]);
}That can change at any time though, and doesn't solve your problem of improperly signed S3 requests. So uploading objects and other operations are going to also fail.
DIf you mean an endpoint different than
https://{account_id}.r2.cloudflarestorage.com/{bucketname}/If it works with S3, it should work with R2 (mostly)
