KNot with the S3 API
KIt worked, thank you and @frederik_b 
KYou can't implement a Worker over the S3 API domain, so you're kind of limited to implementing it all yourself with API keys you make yourself
Ki.e you can make only accept but if it's real keys, I can just go to to talk to
K
KIt's a common problem - i.e you can't bind access to a single KV namespace either using API tokens
KWorkers are the 'go-to' for having more logic, but come with their own drawbacks.
KThe S3 API has a 5GB body limit - you're not getting that yourself unless you're on an Enterprise plan
KAnything 
headersI've never had either of those two work - they internal error when provided with the relevant headers.
KI don't use it personally but it's a blocker for https://github.com/cloudflare/cloudflare-docs/pull/6008
KOn a similar vain, https://github.com/cloudflare/workers-types hasn't ran since the 1st of Sept so the recent R2 changes like
delete
M@john.spurlock re denoflare ... it seems to be bound to one and only one R2 bucket, but still redundantly requires the bucket name be included as a URL path prefix... which could be avoided by configuring S3 tooling that generates presigned URLs to use addressing style... but even that would then require that the bucket name be used as the subdomain where the worker is deployed, and not let me use any domain... am I understanding correctly?
Kgetgetput
K
Kthat and my cursory glance at indicates it's going down a code path that isn't in so my input is limited haha
KKunder
KWould be surprised if there was hard numbers.
KI'd suspect petabytes would get you a call from sales about moving onto an Enterprise plan
Adaily 7tb 
JJust sat down at the desk this morning - I'll take a look at this today, and respond over on the GH issue. Sounds like I'm going to have to do a denoflare release anyway due to Deno introducing their own global implementation in 1.26+ (finally!)