yes

Is that expected to be lifted eventually? Any timeline if so?

k so if using x-amz-copy-source-range that needs to be the same number of bytes too, eh?

For the foreseeable future publishing will require all parts to be the same size (but currently it's required that that's true during upload too)

maybe in the meantime another error code in this case to provide the user with a hint? 500 internal error is inscrutable

I agree.The challenge is we're trying to stick to S3 error codes and this one doesn't exist.... Hmm..

I think we could hide it in the returned message though

Nice. You should be able to still hit 5TB by using 10k 500MB parts

It'll be a bit shy of 5TB because there's some encryption overhead

Appreciate it. I tried writing a reduced test case using our internal runtime test framework (only the R2 responses are stubbed out) and wasn't able to reproduce it.

hehe me and my residential internet connection will... take your word on that : )

Haha.. So would I and my residential internet connection, which isn't all that bad for a residential internet connection 😄

yea even with ~940mbps up, would take almost 12 hrs!

Imagine my poor 200mbps then 😁

Imagine my 5mbps up. 😦

out of interest. does anyone know if r2 will require enterprise plan for a BAA?

(s3 its just a click to sign)

BAA?

@Erwin Business Associate Agreement (HIPAA stuff)

Ahh.. I have no idea about those.. I assume it won't be much different than the rest of Cloudflare (which I also don't have an answer for tbh)

rest of cloudflare is 'enterprise only'

well, for hosting sites

unclear about workers or storge

My naive assumption would be for that to be enterprise only then.. unless stated otherwise.

yea probably :(.. CF is one of the least accessible platforms for healthcare providers unfortunately

Just a heads up since you're using multipart. I'm looking to land the performance improvement for R2 but it looks like the way we manage multipart uploads has a little bit of an issue. You need to make sure to avoid uploading too many parts in parallel for the same uploadId (like 2-3 seems to be asafe limit). Changing it will require a bit of an overhaul of how we do multipart (which is probably a good time to overhaul some of the other stuff you ran into too). This is currently in the backlog for post open beta.

humm, what about my example repo? Could you run both workers and HTTP the API to get the binded worker response into R2?

I haven't tried yet. A couple of slightly higher priority issues came up so the bandwidth of me and another coworker got zapped. Hopefully today we'll try again.

Just a few observations I made when testing the (currently very limited)

Range

header functionality: 1. Returns 200 OK rather than 206 Partial Content. 2. Does not accept

Range: bytes=0-0

(first byte) even though it is a valid range. Remember, the HTTP range header is inclusive the end index. 3. Does not accept

Range: bytes=0-

(all bytes from index

0

and forward - so essentially the entire resource). A lot of browsers sends a HEAD with this range to check if the server supports ranges. 4. Does not accept multiple ranges in any form. Requires that the "range must be in format bytes=start-end.".