Aias00 opened a new issue, #6512:
URL: https://github.com/apache/shenyu/issues/6512

   ### 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!
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to