* 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.
* S3: Fix Content-Encoding header not preserved (#7894)
The Content-Encoding header was not being returned in S3 GET/HEAD responses
because it wasn't being stored in metadata during PUT operations.
Root cause: The putToFiler function only stored a hardcoded list of standard
HTTP headers (Cache-Control, Expires, Content-Disposition) but was missing
Content-Encoding and Content-Language.
Fix: Added Content-Encoding and Content-Language to the list of standard
headers that are stored in entry.Extended during PUT operations.
This matches the behavior of ParseS3Metadata (used for multipart uploads)
and ensures consistency across all S3 operations.
Fixes#7894
* Update s3api_object_handlers_put.go
Javier GarciaandGitHub
Chris LuandGitHub