What is the size limit? Also, is there any difference in caching on different plans?
What is the size limit? Also, is there any difference in caching on different plans?
HFree, Pro and Business customers have a limit of 512 MB.- Default Cache Behavior
For Enterprise customers the default maximum cacheable file size is 5 GB. Contact your account team to request a limit increase.
Cloudflare respects the origin web server’s cache headers in the following order unless an Edge Cache TTL page rule overrides the headers.
AThanks. I am looking for the difference in network quality or other similar factors that may affect experience of the user in terms of performance for different plans. I didn’t find anything on that in the docs.
My use case is video delivery (HLS), video segments would be stored in Cloudflare R2. The video files are broken into many chunks of 10 seconds, so it would be many small files. I want to know if it would make any difference in performance based on plans?
My use case is video delivery (HLS), video segments would be stored in Cloudflare R2. The video files are broken into many chunks of 10 seconds, so it would be many small files. I want to know if it would make any difference in performance based on plans?
AVery slow file download performance on R2, Cache connected but it was a cache MISS. Accessing from Karachi, PK. What could be the reason?
ICloudflare IPs are anycast so that IP address isn't actually in California, it's advertised all over the world and then people connect to the closest one. The IP won't be the issue.
IR2 buckets are created closest to the person who created them - did you create your R2 bucket when connected to the same network you are right now?
ANot the same network. But I created from my workplace which is in same city
IThe 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.jpg and I upload it via R2 dashboard, it shows as being uploaded as somefile, but accessing it via a URL encoded string (needed since anything after # isn't sent to the server by the browser). So the R2 upload process drops anything after the # (same as a browser would do making the request for it). At which point you would be left with an empty file.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.
DYep... I uploaded a file via the dashboard as a test... 
somefile#123.jpg ended up as somefile in the dashboard. I was too scared to try it with a file that started with # because I didn't want to end up an object that wasn't deletable. DSeems so... it's how browsers handle requests with
# in it, so it's not the only place in the world that works that way, but uploading to R2 isn't a normal browser request. Might be something like they are parsing the uploaded R2 object key as a URL path, and if it's a URL path, anything after # would be dropped. It does seem like a bug to me.DOr 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
# isn't valid in an HTTP request.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).