Did you go through https://developers.cloudflare.com/r2/buckets/cors/ ? If so, what is your policy
Did you go through https://developers.cloudflare.com/r2/buckets/cors/ ?
If so, what is your policy set up as?
If so, what is your policy set up as?
Hi did read, i set up cors but same result
Ewhat is your policy set up as?
SErisa, are you aware of how I can potentially stick to Backblaze B2 and provide files through Cloudflare? According to Backblaze, egress costs are zero if done via Cloudflare.
H[
{
"AllowedOrigins": [
"https://anizium.com/",
"https://cdn.anizium.com/",
"https://static.anizium.com"
],
"AllowedMethods": [
"GET",
"POST",
"PUT"
]
}
]EProbably something to the effect of https://www.backblaze.com/blog/free-image-hosting-with-cloudflare-transform-rules-and-backblaze-b2/
But would be off-topic for this channel
But would be off-topic for this channel
Hanybody knows?
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