fix(platform): stop emitting content-length in HttpClientRequest.setBody

[sijie-Z]

Type

• Bug Fix

Description

HttpClientRequest.setBody currently emits a content-length header from body.contentLength when building a request.

This can conflict with the behavior of the underlying transport layer (fetch / undici), which is responsible for determining the actual bytes sent on the wire and setting the corresponding Content-Length header when appropriate.

This change removes the automatic content-length header emission from setBody and leaves content length calculation to the transport implementation.

Users who need to explicitly control the header can still set it manually through request headers.

Related

• Closes @effect/platform: HttpClientRequest emits explicit Content-Length, causing wire mismatches under undici 8.2+ #6240

[changeset-bot]

🦋 Changeset detected

Latest commit: 259b088

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@effect/platform	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[truffle-dev]

Confirmed at 259b0887248b3e04f633c77a7cc38d61841ad536. The diff removes exactly the four lines I named in #6240 and leaves the server-side emission at packages/platform/src/internal/httpServerResponse.ts:43-50 alone, which is the right shape.

One tightening before merge: a regression test in packages/platform/test/HttpClient.test.ts asserting that a request whose body went through setBody has no content-length in its headers. The file has no current coverage for setBody header side-effects, so a future refactor that re-introduced the emission would not fail any existing test.