Skip to content

Adds gzip handler to JDK http client based on header #35225

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

spicydev
Copy link

@spicydev spicydev commented Jul 20, 2025

Title

Implement custom BodyHandler for GZIP decompression in JdkClientHttpRequest

Description

Problem: JDK HTTP Client doesn't automatically decompress responses.

Solution: creating a custom BodyHandler that checks Content-Encoding and applies GZIPInputStream when necessary.
Key Changes:

  • Added new boolean field compressionEnabled to JdkClientHttpRequestFactory and JdkClientHttpRequest.
  • Modified buildRequest() method to add Accept-Encoding header with gzip value when compression is enabled.
  • Added a custom DecompressingBodyHandler that implements BodyHandler<InputStream>. The apply() method in the custom handler checks the Content-Encoding header.
  • If the encoding is gzip, it uses BodySubscribers.mapping to wrap the InputStream with GZIPInputStream.
    Otherwise, it uses the default BodySubscribers.ofInputStream().

Testing Steps:

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jul 20, 2025
Added new flag to JdkClientHttpRequest and created new DecompressingBodyHandler class to handle HttpClient response body decompression when encoded. Closes spring-projectsgh-35222

Signed-off-by: spicydev <[email protected]>
@spicydev spicydev force-pushed the issue/35222_jdk_http_client_compression_feature branch from d20e827 to 3015e29 Compare July 20, 2025 16:11
@bclozel
Copy link
Member

bclozel commented Jul 20, 2025

Should we also support the "deflate" compression algorithm?

Also, I am wondering if we really need an option that enables compression. Should we enable this no matter what?

What do you think?

@bclozel bclozel added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Jul 20, 2025
@spicydev
Copy link
Author

Hi @bclozel, First off let me start off by apologizing for raising the PR in such bad state. I’ll work on unit tests and follow style guide once we can finalize on the requirements.

coming to your questions, Yes we can add support for multiple encoding types but following other clients like apache httpclient & netty, they only support gzip by default out of the box. I think at-least for now we can add support for gzip to JDK http client.

I think it’s better to have the control to the users but by default we can enable compression as it causes no harm but improves performance for all users.

Let me know your thoughts, based on that i can go ahead with changes.

@bclozel
Copy link
Member

bclozel commented Jul 20, 2025

@spicydev no worries, we are here to help.

I think Apache HttpClient supports both. And so does Netty.

Added support for deflate encoded response using InflaterInputStream and added Unit Test cases.

Signed-off-by: spicydev <[email protected]>
@spicydev spicydev force-pushed the issue/35222_jdk_http_client_compression_feature branch from b4e19ea to e463d77 Compare July 26, 2025 16:19
@spicydev
Copy link
Author

Hi @bclozel , Need your help here. When testing the Inflater with JDK http client I'm seeing error like below
java.util.zip.ZipException: incorrect header check. Can you check the unit test once

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: waiting-for-triage An issue we've not yet triaged or decided on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants