Add test suite demonstrating missing transparent HTTP compression support

[Copilot]

Java HTTP Client lacks transparent HTTP compression—applications must manually add Accept-Encoding headers and decompress responses. This creates unnecessary complexity and bandwidth waste.

Changes

Test Suite (JavaHttpClientCompressionTest)

5 tests demonstrating current limitations:

• No automatic Accept-Encoding header insertion (HTTP/HTTPS)
• No automatic gzip decompression of responses
• Manual implementation required for compression support

// Current: manual compression required
HttpRequest request = HttpRequest.newBuilder()
    .uri(uri)
    .header("Accept-Encoding", "gzip")  // Manual
    .GET()
    .build();

HttpResponse<byte[]> response = client.send(request, HttpResponse.BodyHandlers.ofByteArray());

// Manual decompression needed (15+ lines of GZIPInputStream handling)
if ("gzip".equals(response.headers().firstValue("content-encoding").orElse(""))) {
    // ... decompress manually ...
}

Documentation

• HTTP_COMPRESSION.md: Technical specification proposing transparent compression similar to curl/browsers—automatic Accept-Encoding insertion and response decompression with opt-out via Accept-Encoding: identity
• GITHUB_ISSUE_SUMMARY.md: JDK enhancement request draft for OpenJDK submission

Test Infrastructure

• Enhanced NettyHttp2Server with gzip compression support for test validation
• Updated README with compression test documentation

All tests pass. Ready for use as supporting material for JDK enhancement request.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Create Testcase for missing (transparent) compression support</issue_title>
<issue_description>HTTP compression is an important part even on today's modern hardware and increasing transfer speeds:

1. it reduces load on the wire, even if connections often fast they are not always e.g. MobileConnections still can suffer
2. the sooner a transfer is done the better as often servers are more limited by the number of connections to handle
3. As compression is completely basic concept in HTTP many proxies even cache compressed contents, asking for uncompressed content then can lead to a cache miss and higher loads/slower downloads
4. encryption might benefit as well as it requires less bytes to be encrypted/decrypted and in general reduncy is bad for ciphertext

Currently javahttpclient does not support compression out of the box, it needs to be added on the user-leve what has many major drawbacks:

1. the effort to implement it has to be taken for each application
2. the implementation is not trivial and usually requires work on the request and response side blowing up the code
3. it is easily forgotten, or not implemented for the above reasons or incomplete or even buggy
4. Transport level compression is not really an application level concern e.g. it can happen transparently.

Our goal here is to:

• create a testsuite that shows compression is NOT performed automatically and requires manual work
• create a document HTTP_COMPRESSION.md with a summary that can act as a base to be submitted as an enhancement request to the JDK
• a short summary to be used for a github issue tracking the progress

The proposed solution here should be:

Java Http Client by default adds Accept-Encoding: gzip, deflate (or whatever seems suitable here as a default) if not given by the user. This then switches the request into a "transparent mode" where when the server replies with Content-Encoding: gzip for example, the content is transparently decoded and one can use it e.g. in a BodyHandler without special considerations.

A user still can use its own, or specifically disable that feature by setting the header Accept-Encoding: identity (see https://datatracker.ietf.org/doc/html/rfc2616#section-14.3) servers are always free to ignore the request (see https://datatracker.ietf.org/doc/html/rfc2616#section-14.41)</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Create Testcase for missing (transparent) compression support #14

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.