fix(storage): send explicit Content-Length on every S3 request

[ArnabChatterjee20k]

Problem

Uploading large (chunked) files to S3-compatible storage — reported against GCS — fails with:

HTTP 411 — POST requests require a Content-length header

Reported downstream in appwrite/appwrite#13548 (self-hosted 2.0, files 15 MB–550 MB).

Cause

S3::call() handed a streamed body to the client transport without a Content-Length header. The cURL adapter then:

• streams a body of unknown size (StreamInterface::getSize() returns null) with Transfer-Encoding: chunked, and
• emits no length header at all for an empty-body POST (e.g. createMultipartUpload).

Many S3-compatible services (GCS in particular) reject both with 411.

Fix

hashBody() already reads the whole (seekable) body once to sign it, so it now also counts the bytes and returns the length. call() sets an explicit, signed content-length header on every request (0 for empty bodies). The value is the full body size, so it matches what the transport already sends for a size-known stream — no behavioural change there, correct headers for the streamed / empty-body cases. No new reads of the body are introduced.

Ports the fix from the archived standalone utopia-php/storage PR #171 into the monorepo (packages/storage).

Testing

• php -l clean; single hashBody caller updated.
• Vendor deps not installed in this checkout, so PHPUnit/PHPStan not run locally — CI will cover.

Fixes appwrite/appwrite#13548

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the S3 request-length behavior is implemented consistently and covered through observable public behavior.

Summary

• Prevents unknown-size streams from falling back to chunked transfer encoding.
• Covers exact streamed-body length through the public write() API.
• Covers empty multipart-initiation requests through the public prepare() API.

_{Reviews (3) · Last reviewed commit: "test(storage): reach empty-body multipar..."}