[BUG] Logging console decompresses gzip response bodies per buffer chunk
- Dominant language
- Java
- Stars
- 8.8k
- Forks
- 3.1k
- Avg merge
- 7d 1h
- Merged PRs (30d)
- 85
Description
### Search before asking
- [x] I had searched in the [issues](https://github.com/apache/shenyu/issues) and found no similar issues.
### Apache ShenYu Component
shenyu-plugin
### What happened
`LoggingConsolePlugin` logs response bodies by iterating each emitted `DataBuffer`. For gzip responses, it tries to decompress each individual buffer chunk as if it were a complete gzip stream:
```java
return Flux.from(body).doOnNext(buffer -> {
try (DataBuffer.ByteBufferIterator bufferIterator = buffer.readableByteBuffers()) {
bufferIterator.forEachRemaining(byteBuffer -> {
if (serverHttpResponse.getHeaders().containsKey(Constants.CONTENT_ENCODING)
&& serverHttpResponse.getHeaders().getFirst(Constants.CONTENT_ENCODING).contains("gzip")) {
try {
ByteBuffer readOnlyBuffer = byteBuffer.asReadOnlyBuffer();
byte[] compressed = new byte[readOnlyBuffer.remaining()];
readOnlyBuffer.get(compressed);
byte[] decompressed = decompressGzip(compressed);
writer.write(ByteBuffer.wrap(decompressed));
} catch (IOException e) {
LOG.error("Failed to decompress gzipped response", e);
writer.write(byteBuffer.asReadOnlyBuffer());
}
} else {
writer.write(byteBuffer.asReadOnlyBuffer());
}
});
}
})
```
A gzip response body can be split across multiple `DataBuffer`s. In that case only the complete gzip stream can be decompressed correctly; individual chunks are usually not valid standalone gzip streams. When the stream is split, the logger emits decompression errors and falls back to writing compressed bytes for failed chunks, so the console response body log becomes corrupted or unreadable.
The actual proxied response is still forwarded, but the logging-console output is incorrect for normal chunked gzip responses.
### Expected behavior
The logging plugin should aggregate the gzip bytes for logging before decompression, or use a streaming gzip decoder that handles data split across buffers. It should not attempt to create a new `GZIPInputStream` for every `ByteBuffer` chunk.
### How to reproduce
1. Enable logging-console with response body logging.
2. Proxy an upstream endpoint that returns `Content-Encoding: gzip` and a response body large enough to be emitted in multiple buffers.
3. Inspect the console response body log.
4. The plugin logs `Failed to decompress gzipped response` for chunks that are not complete gzip streams and records compressed/corrupted bytes instead of the decompressed response body.
### Debug logs
_No response_
### Environment
Current `master` branch.
### Are you willing to submit a PR?
- [ ] Yes I am willing to submit a PR!
Contributor guide
No contributing guide indexed for this repository
Research direction
Locate LoggingConsolePlugin and inspect how its response-body Flux handles DataBuffer chunks, including decompressGzip. Reproduce with a chunked gzip response, then verify that the console log contains the complete decompressed body without per-chunk decompression errors; add or update focused tests if the relevant test location is found.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100