* s3: allow up to 50 tags in a bucket tag set
PutBucketTagging validated the tag set with the object tag rules, which
allow 10 tags. AWS allows a bucket up to 50 tags, so tag sets of 11 to 50
tags were rejected with InvalidTag. Validate bucket tags against 50 and
keep the limit of 10 for objects and S3 Tables.
A tag set that repeats a key is rejected with InvalidTag, as AWS does,
instead of keeping one of the values, so 51 tags with a repeated key no
longer pass as 50.
* s3: reject duplicate tag keys in PutObjectTagging
The tag set collapses to a map, so a repeated key was silently kept once.\nMatch the bucket tagging check and answer InvalidTag instead.
* s3: reject empty tag keys
AWS requires a tag key to be at least one character; the shared\nvalidator only checked the 128-char upper bound.
* s3: reject duplicate tag keys in the tagging header parser
parseTagsHeader (the x-amz-tagging path used by CopyObject with
TaggingDirective=REPLACE) silently kept the last value when a key
repeated, while the PutObject and multipart header paths and the new
XML checks return InvalidTag for the same input. A repeated key after
URL decoding now fails the same way.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* s3: validate x-amz-tagging tags on PutObject before storing the entry
The header path only rejected duplicate keys, so an upload could store
more than ten tags or keys and values that fail S3 tag rules. Run the
parsed set through ValidateTags like the XML tagging handlers do.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* s3: validate x-amz-tagging tags on multipart initiate
ParseS3Metadata stored header tags with no tag-set validation, the same
gap putToFiler had. Multipart uploads now reject oversize or malformed
tag sets with InvalidTag.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* s3: count tag length in characters, not bytes
* s3: validate object tags before uploading chunks
* s3: reuse parseTagsHeader and drop raw header from warnings
---------
Co-authored-by: Wleeaf <179125857+wleeaf@users.noreply.github.com>
Co-authored-by: user.email <chrislusf@users.noreply.github.com>
Co-authored-by: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Multipart initiation stored client-supplied Seaweed-X-Amz-Acl and
Seaweed-X-Amz-Owner request headers onto the upload entry, and
CompleteMultipartUpload copied them to the finished object, letting a
caller forge ownership or a public ACL without s3:PutObjectAcl.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
* 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
