SigV2 hasn't been supported on any AWS regions launched after 2013
SigV2 hasn't been supported on any AWS regions launched after 2013
KI don't think it's on the way personally
I2013, whew.
KThe Europe (Frankfurt), US East (Ohio), Canada (Central), Europe (London), Asia Pacific (Seoul), Asia Pacific (Mumbai), Europe (Paris), China (Ningxia), Europe (Stockholm), Asia Pacific (Osaka Local), AWS GovCloud (US-East), and Asia Pacific (Hong Kong) Regions were launched after 2013, and support SigV4 but not SigV2. If you have code that accesses S3 buckets in that region, it is already making exclusive use of SigV4.
K
KIt do be oldddddd
IWhat about v3? 
KThe HyperText Transfer Protocol (HTTP) 411 Length Required client error response code indicates that the server refuses to accept the request without a defined Content-Length header.
KR2 requires a
Content-Length header for uploadsKIt'll work on S3 when using MP uploads iirc but that's about it
BHmm... content length isn't required for MP part uploads?
BI'll look into it
BA release was made:
- Unsupported search paramters to ListObjects/ListObjectsV2 are now rejected with 501 NotImplemented.
- Fixes for Listing:
- Fix listing behavior when the number of files within a folder exceeds the limit (you'd end up seeing a CommonPrefix for that large folder N times where N = number of children within the CommonPrefix / limit).
- Fix corner case where listing could cause objects with sharing the base name of a "folder" to be skipped.
- Fix listing over some files that shared a certain common prefix.
- DeleteObjects can now handle 1000 objects at a time.
B@john.spurlock for visibility on the listing fixes.
K
Jnice, thanks!
Jsemi-permeable code freeze
BOh & deletion of multiple objects should now be faster too.
BCode freeze window ended this morning
Jright before the holiday eh
BSo I looked into it and there's this:
https://stackoverflow.com/questions/69899949/upload-with-high-level-multipart-still-gives-no-content-length-specified-warning
This indicates it is indeed required even for S3. I haven't figured out a good way to actually test out omitting the content-length
https://stackoverflow.com/questions/69899949/upload-with-high-level-multipart-still-gives-no-content-length-specified-warning
This indicates it is indeed required even for S3. I haven't figured out a good way to actually test out omitting the content-length
Stack Overflow
Even though I'm using the high level multipart I'm still getting the warning in the console:
WARN - com.amazonaws.services.s3.AmazonS3Client - No content length specified for stream data. Stream
WARN - com.amazonaws.services.s3.AmazonS3Client - No content length specified for stream data. Stream
BGitLab
New description proposal Based on gitlab-org/gitlab-ee#4184 we know that only GCS (Google Cloud Storage) accepts chunked-encoding, all the other S3-compatible
BBased on gitlab-org/gitlab-ee#4184 we know that only GCS (Google Cloud Storage) accepts chunked-encoding, all the other S3-compatible Object Storage requires Content-Length HTTP header.
BThat's not part of S3 AFAIK.
BSo you're saying that GitLab is working for you with AWS S3 & not with R2?
BOr are you using GitLab with GCS?
BDo you make sure to disable
enable_signature_v4_streaming ?BStreaming Sigv4 is the only part of the spec I see that potentially omits Content-Length
B(although you still provide the length, just via the
x-amz-decoded-content-length header)BDM me your account ID so I can double-check
BI'm seeing some 200 puts from your end
Bso not all are failing
BAll your multipart uploads are OK
BI don't know what the issue is but it doesn't seem like it's on the R2 side of things
BI do notice that the successful puts aren't presigned
Bso maybe that's logpush
