3 ms·

Thanks for the awesome product! I have a few questions: 1. Are the rate limits for all users on a given bucket, or by source IP as some other providers do? 2.

Thanks for the awesome product! I have a few questions: 1. Are the rate limits for all users on a given bucket, or by source IP as some other providers do? 2. What is the plan for the rate limits post beta? 3. Do you support the x-amz-content-sha256 header. i.e. If a put contains that header and the content hash doesn't match is it rejected? 4. What does it mean to support pre-signed URLs? Can't a client pre-sign a URL that anyone else can use? My understanding is they are the same as normal usage from the server's perspective, just the key holder signs the request, and the other person actually makes the request. 5. Why is the read limit smaller than the write limit?

taylor12345 4y ago
I'm also an engineer on R2 team. 1 & 2 - We're reserving some ability to rate-limit during beta as we figure out how best to scale our systems under load. I'll defer to vlovich & greg-m for post-beta plans. 3. We do support that header. Mismatching content hashes will be rejected during write. If you ever experience otherwise, please report it. 4. We only support sigv4 auth via header currently: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-u... With presigned urls, we will support sigv4 in url parameters https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-... 5. See #1. We'll be improving the throughput of both operations, but currently reads have higher throughput than writes.
- InvaderFizz 4y ago
  On the subject of sigv4, are you going to allow longer than 7 day lifetimes for presigned URLs?
- ianopolous 4y ago
  Thank you, that makes sense. So presigned URLs that use auth header are fine (We use those extensively in Peergos, as presigned with an auth query parameter isn't cached by browsers as the query string will change with subsequent requests).

taylor12345 4y ago

I'm also an engineer on R2 team. 1 & 2 - We're reserving some ability to rate-limit during beta as we figure out how best to scale our systems under load. I'll defer to vlovich & greg-m for post-beta plans. 3. We do support that header. Mismatching content hashes will be rejected during write. If you ever experience otherwise, please report it. 4. We only support sigv4 auth via header currently: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-u... With presigned urls, we will support sigv4 in url parameters https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-... 5. See #1. We'll be improving the throughput of both operations, but currently reads have higher throughput than writes.

InvaderFizz 4y ago
On the subject of sigv4, are you going to allow longer than 7 day lifetimes for presigned URLs?
ianopolous 4y ago
Thank you, that makes sense. So presigned URLs that use auth header are fine (We use those extensively in Peergos, as presigned with an auth query parameter isn't cached by browsers as the query string will change with subsequent requests).