Probably. You'll get back a 412 if the precondition fails, in this case it already exists with that
Probably. You'll get back a 412 if the precondition fails, in this case it already exists with that ETag
KI looked at the middleware but my brain isn't equipped to see how you set it up to accept arguments from the since you'd want to be able to pass the digest of the file into the header
KCan't be as bad as aws-sdk-go
K
K
KAh - you can add the middleware to the command as opposed to the entire client.
KThe dark side of API extensions - the lack of tooling compat
K
K
KIt works fine with presigned, if all else fails.
KI suspect middleware is the way to go for the SDK though
KKyes it's ugly but that's how you'd do it
Kit does throw an error since it got a response back - so that'll want handling
KUnfortunately it still seems to be broken in the Worker's API - when passing to
KDitto with passing to
KNeither of those two play nicely - and if it's not happy with the provided headers then I suspect there's an issue with how it's parsing them since public buckets / S3 API / other websites in general accept the same headers.
KIt worked, thank you 
KWell, let me check that, just finished it with axios 
Kthis is the SDK middleware approach
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 related seems to go 
KKI'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 accepting and everything else included in that release isn't included.
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?
K works fine
K with doesn't and with doesn't
K
K