* s3api: do not store aws-chunked in an object's Content-Encoding
aws-chunked in Content-Encoding names the SigV4 streaming framing of
the request body, which the gateway decodes on upload. PutObject and
CreateMultipartUpload stored the header as sent, so an object uploaded
with "gzip, aws-chunked" was served with that Content-Encoding, and one
uploaded with "aws-chunked" alone was served as aws-chunked. S3 drops
aws-chunked and keeps the other encodings.
Also run ceph/s3-tests' test_object_content_encoding_aws_chunked in CI.
* s3api: read every Content-Encoding field, and drop aws-chunked on copy
A client can send aws-chunked and the object's own encoding as separate
Content-Encoding fields. Only the first was read, so "aws-chunked"
followed by "gzip" left the object without its gzip. Combine all the
fields before dropping aws-chunked. CopyObject with the REPLACE
directive stored the requested Content-Encoding as sent: drop
aws-chunked there too.
* fix: support standard HTTP headers in S3 multipart upload
* fix(s3api): validate standard HTTP headers correctly and avoid persisting Response-Content-Disposition
---------
Co-authored-by: steve.wei <coderushing@gmail.com>
* list owned buckets
* simplify
* add unit tests
* no-owner buckets
* set identity id
* fallback to request header if iam is not enabled
* refactor to test
* fix comparing
* fix security vulnerability
* Update s3api_bucket_handlers.go
* Update s3api_bucket_handlers.go
* Update s3api_bucket_handlers.go
* set identity to request context
* remove SeaweedFSIsDirectoryKey
* remove obsolete
* simplify
* reuse
* refactor or remove obsolete logic on filer
* Removed the redundant check in GetOrHeadHandler
* surfacing invalid X-Amz-Tagging as a client error
* clean up
* constant
* reuse
* multiple header values
* code reuse
* err on duplicated tag key
Javier Garcia