Search before asking
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:
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 DataBuffers. 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
- Enable logging-console with response body logging.
- Proxy an upstream endpoint that returns
Content-Encoding: gzip and a response body large enough to be emitted in multiple buffers.
- Inspect the console response body log.
- 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?
Search before asking
Apache ShenYu Component
shenyu-plugin
What happened
LoggingConsolePluginlogs response bodies by iterating each emittedDataBuffer. For gzip responses, it tries to decompress each individual buffer chunk as if it were a complete gzip stream:A gzip response body can be split across multiple
DataBuffers. 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
GZIPInputStreamfor everyByteBufferchunk.How to reproduce
Content-Encoding: gzipand a response body large enough to be emitted in multiple buffers.Failed to decompress gzipped responsefor chunks that are not complete gzip streams and records compressed/corrupted bytes instead of the decompressed response body.Debug logs
No response
Environment
Current
masterbranch.Are you willing to submit a PR?