buildMultipartSSES3Reader opened a volume-server HTTP response for EVERY
chunk upfront, then walked them with io.MultiReader. For a multipart
SSE-S3 object with N internal chunks (e.g. a 200MB Docker Registry blob
with 25+ chunks), N volume-server bodies sat live at once; chunks
1..N-1 were idle while io.MultiReader drained chunk 0. Under concurrent
load the volume server's keep-alive logic closed those idle responses
mid-flight, and the S3 client saw `unexpected EOF` partway through the
GET. Truncated bytes hash to the wrong SHA-256, which is exactly the
"Digest did not match" symptom Docker Registry reports in #8908 (and
which persisted even after the per-chunk metadata fix in #9211 and the
completion backfill in #9224).
Introduce lazyMultipartChunkReader + preparedMultipartChunk{chunk,
wrap}: a generic lazy chunk streamer with a per-chunk wrap closure for
the SSE-specific decryption setup. Per-chunk metadata is still
validated UPFRONT so a malformed chunk fails fast without opening any
HTTP connection -- the eager validation contract callers and tests
rely on is preserved. The volume-server GET and the SSE-specific
decrypt wrap, however, fire LAZILY: at most one chunk body is live at
any time, regardless of object size.
This commit applies the new pattern to buildMultipartSSES3Reader only;
the SSE-KMS and SSE-C multipart readers retain their eager form for
now and will be migrated in follow-up commits, since the same shape
exists there too.
Tests:
- TestBuildMultipartSSES3Reader_LazyChunkFetch pins the new contract:
zero chunks opened at construction, peak liveness == 1, all closed
after drain.
- TestBuildMultipartSSES3Reader_RejectsBadChunkBeforeAnyFetch
(replaces ClosesAppendedOnError) asserts a malformed chunk in
position N causes zero fetches for chunks 0..N -- the previous
test pinned a weaker contract (cleanup after eager open).
- TestBuildMultipartSSES3Reader_InvalidIVLength updated for the same
reason: the fetch callback must NOT be invoked at all on a bad-IV
chunk.
- TestMultipartSSES3RealisticEndToEnd round-trips multiple parts
encrypted the way putToFiler writes them (shared DEK + baseIV,
partOffset=0, post-completion global offsets) and walks them
through buildMultipartSSES3Reader.
see https://blog.aqwari.net/xml-schema-go/
1. go get aqwari.net/xml/cmd/xsdgen
2. Add EncodingType element for ListBucketResult in AmazonS3.xsd
3. xsdgen -o s3api_xsd_generated.go -pkg s3api AmazonS3.xsd
4. Remove empty Grantee struct in s3api_xsd_generated.go
5. Remove xmlns: sed s'/http:\/\/s3.amazonaws.com\/doc\/2006-03-01\/\ //' s3api_xsd_generated.go
Chris Lu
7bc87bec07