apache / apache/shenyu

[BUG] Logging console decompresses gzip response bodies per buffer chunk

Open
#6,512 1 comment 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.