-
[OPIK-7281] Fix outbound gzip response double-decompression (#7413)
frostbyte_neo 发布于
2026-07-10 14:20:08 +00:00 - [OPIK-7281] Fix outbound gzip response double-decompression
With jerseyClient.gzipEnabled: true, Dropwizard wires both Apache HttpClient's
transparent content decompression and Jersey's GZipDecoder. HttpClient decodes the
body but the stale Content-Encoding: gzip header survives into the Jersey response,
so GZipDecoder gunzips the already-plain stream and readEntity throws
java.util.zip.ZipException: Not in GZIP format on any outbound call reading a
gzipped body without a per-call identity-encoding workaround (e.g. OllamaService).Register a ClientResponseFilter on the shared client (gated on gzipEnabled) that
strips the stale Content-Encoding/Content-Length after HttpClient's decode, leaving
exactly one decode while keeping Accept-Encoding: gzip on the wire. Adds a
regression test built with gzipEnabled: true, the path config-test.yml skips.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7281] Make gzip regression test serve an explicit gzipped response
Address review: the test relied on WireMock's default auto-gzip, which made the
double-decompression path dependent on WireMock config. Serve an explicitly gzipped
body with Content-Encoding: gzip from a WireMock server with auto-gzip disabled, so
the path is exercised deterministically regardless of WireMock defaults. Verified it
still fails with ZipException when the reconciling filter is removed.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- [OPIK-7281] Address review nits on the response filter
- Add @NonNull validation on the public filter() responseContext parameter.
- Use String.strip() instead of trim() for the Content-Encoding value.
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
下载附件