[Guzba]

The example shows leaving your bucket name in the url as a way to filter out requests to other bucket names. If you want your static site to have http://mysite.com/bucketname/index.html then I guess that's ok. But again, careful configuration and still not for every situation.

I'm sure you can layer more rules to get it exactly right but I'd not be eager to layer on complex configuration through multiple service providers when it is avoidable, unless there is some very compelling overriding reason.

[gfs]

As far as I know, bucket names must be unique at other providers like AWS as well. [0]

I'm no expert but to try and protect my own domain, I use a transform rule to match a subdomain and append "/file/$MY_BUCKET_NAME" to each request. This should return a 404 for anybody who tries to inject their own bucket in the path. I could be wrong of course.

[0]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket...

[eropple]

Bolting a Cloudfront distribution onto a S3 bucket is pretty well-trod territory, though, and doesn't have these sharp edges. (Has a couple other ones, but they're less common.)

[radlad]

This is an easily solved problem. Backblaze has an example here: https://github.com/backblaze-b2-samples/cloudflare-b2

[Guzba]

Does the solution involve using Cloudflare workers? Because, as I said, I'm sure it is possible but maybe we've gone off the deep end a bit. Just how crazy of a configuration do you want just to serve files from an object store?

This looks like an awful lot of setup for "easily solved". Easily solved is what S3 does where this isn't even a problem.

[silverlyra]

  curl -sL https://github.com/backblaze-b2-samples/cloudflare-b2/raw/main/README.md | head -n 1
  # Cloudflare Worker for Backblaze B2

yes, it's a worker