John Yin created CAMEL-24234:
--------------------------------
Summary: camel-http throws ZipException: Not in GZIP format
against any gzip-compressing server with default settings
Key: CAMEL-24234
URL: https://issues.apache.org/jira/browse/CAMEL-24234
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 4.18.3
Environment: * {*}Environment{*}: Camel 4.18.3, {{camel-http}}
(HttpClient 5 backend), Java 25 (in Spring Boot 3.5.16)
Reporter: John Yin
* {*}Steps to reproduce{*}: minimal route {{.to("https://www.google.com";)}}
with no special config
* {*}Expected{*}: response is returned successfully (compression should be
transparent by default)
* {*}Actual{*}:
java.util.zip.ZipException: Not in GZIP format
at java.base/java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:231)
at java.base/java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:86)
at java.base/java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:118)
at org.apache.camel.support.GZIPHelper.uncompressGzip(GZIPHelper.java:41)
at
org.apache.camel.component.http.HttpProducer.extractResponseBody(HttpProducer.java:543)
at
org.apache.camel.component.http.HttpProducer.populateResponse(HttpProducer.java:363)
at
org.apache.camel.component.http.HttpProducer.lambda$process$1(HttpProducer.java:277)
at
org.apache.camel.component.http.HttpProducer.executeMethod(HttpProducer.java:500)
at org.apache.camel.component.http.HttpProducer.process(HttpProducer.java:253)
at
org.apache.camel.support.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:65)
at
org.apache.camel.processor.SendProcessor.sendUsingProducer(SendProcessor.java:253)
at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:158)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:1105)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:1048)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.doRun(DefaultReactiveExecutor.java:199)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.executeReactiveWork(DefaultReactiveExecutor.java:189)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.tryExecuteReactiveWork(DefaultReactiveExecutor.java:166)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:59)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:162)
at
org.apache.camel.impl.engine.CamelInternalProcessor.processNonTransacted(CamelInternalProcessor.java:385)
at
org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:361)
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:293)
at
org.apache.camel.component.timer.TimerConsumer$1.doRun(TimerConsumer.java:164)
at org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:136)
at java.base/java.util.TimerThread.mainLoop(Timer.java:579)
at java.base/java.util.TimerThread.run(Timer.java:529).
* *Root cause* (worth including — reviewers move faster on well-diagnosed
reports): HttpClient5 auto-decompresses by default but leaves the
{{Content-Encoding: gzip}} response header in place; {{HttpProducer}} doesn't
check whether decompression already happened before re-attempting it via
{{GZIPHelper}}
* {*}Workaround found{*}: {{contentCompressionDisabled=true}} on the component
avoids the double-decompression, but this isn't documented as a _required_
setting anywhere, and it's non-obvious that leaving compression at its default
is what breaks things
* {*}Suggested fix direction{*}: either (a) {{HttpProducer}} should check
whether the entity was already decompressed by HttpClient5 before invoking
{{{}GZIPHelper{}}}, or (b) the component docs should clearly state that
{{contentCompressionDisabled=true}} is effectively required for correct
behavior against compressing servers, or (c) default
{{contentCompressionDisabled}} to {{true}} so Camel's own handling is the sole
decompression path
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
