ProcessStreamingResponseBody is skipped when response contains Content-Encoding

[h2cone]

Issue Description

ProcessStreamingResponseBody is skipped when the response has Content-Encoding.

Describe what happened

In our environment, we can repeatedly observe:

• when response header contains Content-Encoding: gzip, ProcessStreamingResponseBody is not executed;
• when response has no Content-Encoding, ProcessStreamingResponseBody is executed normally.

Important clarification:

• request Accept-Encoding is only an indirect factor;
• the direct trigger appears to be whether response Content-Encoding is present.

From current code reading, this seems related to wrapper behavior:

• pkg/wrapper/request_wrapper.go: IsBinaryResponseBody() returns true if content-encoding is non-empty;
• pkg/wrapper/plugin_wrapper.go: response header phase may set needResponseBody=false, then response-body callbacks are skipped.

If there is an exception, please attach the exception trace:

No panic/stack trace. This is behavior mismatch in callback triggering.

Describe what you expected to happen

Expected behavior:

• plugins registered with ProcessStreamingResponseBody should have deterministic callback behavior;
• response compression should not silently disable callbacks without explicit configuration or clear warning.

How to reproduce it (as minimally and precisely as possible)

1. Deploy a route with a WASM plugin that registers ProcessStreamingResponseBody.
2. Route traffic to an upstream endpoint that always returns compressed response (Content-Encoding: gzip).
3. Send a normal request to that route and check plugin/gateway logs.
4. Observe callback is not triggered (callback=NOT_EXECUTED).
5. Switch to an uncompressed upstream endpoint (Content-Encoding absent) and call again.
6. Observe callback is triggered (callback=EXECUTED).

Anything else we need to know?

Relevant log evidence from our run:

• compressed response: response.content-encoding="gzip" with callback=NOT_EXECUTED
• uncompressed response: response.content-encoding="" with callback=EXECUTED

Potential improvements that would help users:

1. add a configurable option to keep response-body callbacks enabled when Content-Encoding exists (raw bytes acceptable);
2. optionally support transparent decompression before callback;
3. if current behavior is intentional, add explicit docs/log hints.

Environment:

• Higress version: v2.1.9
• Others: reproducible with custom WASM plugin using ProcessStreamingResponseBody

[johnlanni]

This is by design, as the compressed message cannot be processed in the plugin logic