RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2]

[Volkan Yazici]

On Fri, 10 Oct 2025 12:04:28 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown.
>> 
>> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110.
>> 
>> The existing ContentLengthHeaderTest was extended to cover the modified scenarios.
>> 
>> Tier1-3 tests continue to pass.
>
> Daniel Jeliński has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test explicitly setting content length to zero

### Why is this an HTTP/1.1-only problem?

HTTP/2 and HTTP/3 implementations of `HttpClient` already add the `Content-Length` header iff it is greater than zero:

https://github.com/openjdk/jdk/blob/4728f746a89ca7cb787b3d9969f09a80cc92f502/src/java.net.http/share/classes/jdk/internal/net/http/Stream.java#L906-L908
https://github.com/openjdk/jdk/blob/4728f746a89ca7cb787b3d9969f09a80cc92f502/src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java#L388-L390

They do this, unlike the `POST` and `PUT` exemption for HTTP/1.1 in the proposed PR, for all methods.
This behavior difference between HTTP/1 and HTTP/{2,3} is not a problem because

1. HTTP/2 and HTTP/3 are implicitly chunked when `Content-Length` is missing.
2. `Content-Length` is always optional for HTTP/2 and HTTP/3, for all methods. A user agent may add it, in which case it must match the total number of bytes sent in the body request.

**Credits:** Thanks to @dfuch and @djelinski for patiently answering my questions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27727#issuecomment-3396762951