KWhat console errors are you getting?
K- Have the files in a Backblaze bucket
- Set up a Cloudflare CNAME to proxy the bucket, the orange cloud must be turned on
- Set up some extra Cache Rules for this CNAME to make sure all content is cached (and you set the durations, other config you want)
- Your Backblaze bill should start reflecting the free egress soon. You can have Backblaze support confirm it's correctly set up
KAlso turn on the Tiered Cache too, it's free and works with B2
TSame issue here. It's working fine for me on chrome/safari but failing on firefox.
TOnly in Firefox for some reason. Chrome and safari are fine
AHello, Cloudflare Team.
I have a question about Cloudflare R2.
I want to open all Buckets and Files via S3 Client i.e. S3 Browser. However, when I try it it generates an error.
Is this an error from Cloudflare or from S3 Browser?
Then, is there an S3 Client that can access Cloudflare R2?
Thank You.
I have a question about Cloudflare R2.
I want to open all Buckets and Files via S3 Client i.e. S3 Browser. However, when I try it it generates an error.
Is this an error from Cloudflare or from S3 Browser?
Then, is there an S3 Client that can access Cloudflare R2?
Thank You.
AHello, Cloudflare Team.
I've found an S3 Client that can access Cloudflare R2.
It's called CyberDuck https://cyberduck.io/
Thank You.
I've found an S3 Client that can access Cloudflare R2.
It's called CyberDuck https://cyberduck.io/
Thank You.
SYou could create HLS stream files and upload it to R2
PWinSCP wasn't working long time ago and i reported, there were no replies
ECould you try again (with WinSCP)? R2 made a number of compatbility improvements in the last year and I'd be curious what issues its stiill having if any
EIts an error from Cloudflare telling you that it doesn't support the auth scheme that S3 Browser is trying to use. Does the application have an option to use V4 auth instead?
Pi tried recently and it doesn't work
EAny idea what error it gives? Or just generic?
P"The request signature we calculated does not match the signature you provided. Check your secret access key and signing method."
EI see
EThanks
Pi've regenrated 10+ times the credentals and no it doesn't fix the issue
Pevery time when it reaches 5120KB it stops and pops this error
Pi am on the latest version of WinSCP
EAh, probably something to do with multipart then
Pdunno
Puploading to b2 works, s3 works, only r2 is not (with this error)
VIs there a speed difference between accessing the bucket via a public url and from a worker?
VOr rather, should there be a difference? I'm seeing lower latencies across the board when accessing files from inside a Worker
VWhat could be the reason behind it?
EIts expected that Workers will have lower latency but the difference shouldnt be too dramatic - what numbers are you seeing? And is it tested from the same regions?
Vblue: worker
gray: public url
gray: public url
Vit's not too dramatic tbh, i just wanted to know the fastest possible option
Vi'm curious, why is it faster via a Worker? Doesnt the worker itself add like 30ms latency? Or with the worker the request gets on the cf backbone faster?
EWorkers dont add 30ms latency to requests
EIf I recall correctly I believe it was something to do with the binding not having as much auth overhead, like for S3 you have to sign the request and then verify the signature and all that stuff because the request goes through
EPublic URL I'm not so sure on
VSeems like a valid explanation yeah..
How much overhead do workers add to a request? I mean it can't possibly be 0
How much overhead do workers add to a request? I mean it can't possibly be 0
Vhttps://blog.cloudflare.com/cloudflare-workers-the-fast-serverless-platform/ this shows around 20ms TTFB in US regions
VAlso, based on these outcomes should I just serve my files via Worker and not a public URL?
D20ms sounds about right, the worker is loaded while TLS handshake & validation and everything is performed, so you don't really see the cold starts as much
VI just ran an artillery load test too, and files via workers is almost 2x.. guess i'll disable the public url and serve assets via workers
EThat 20ms would be for the whole request, not just the added latency from Workers
Vis
s-maxages-maxageIt does not seem like it 
it does not get stripped and from that i'm assuming it's not getting cached
it does not get stripped and from that i'm assuming it's not getting cachedPi think not, just like pages.dev (iirc)
just bind a custom domain
just bind a custom domain
VSolution was that I needed to add the correct extension to the end of the filenames (was just using UUIDs) so that CF would cache them.
as per: https://developers.cloudflare.com/cache/concepts/default-cache-behavior/#default-cached-file-extensions
as per: https://developers.cloudflare.com/cache/concepts/default-cache-behavior/#default-cached-file-extensions
HHi, if I make an R2 bucket public, can the files in the R2 bucket be seen, or are files only available to clients if they know the file name?
ETheres no listing functionality for public, its only if they know the filename