feat: configurable transport compression strategy#19454
Conversation
FrankChen021
left a comment
There was a problem hiding this comment.
| Severity | Findings |
|---|---|
| P0 | 0 |
| P1 | 1 |
| P2 | 1 |
| P3 | 0 |
| Total | 2 |
Reviewed 3 of 3 changed files.
This is an automated review by Codex GPT-5.5
| return new JsonParserIterator<>( | ||
| queryResultType, | ||
| future, | ||
| wrapFutureWithDecompressor(future, responseContentEncoding.get()), |
There was a problem hiding this comment.
[P1] Decompressor choice races the response headers
The decompressor is selected from responseContentEncoding.get() when the Sequence iterator is created, which can happen immediately after run() returns and before the async HTTP handler has seen the response headers. In that common path this passes an empty encoding and returns the original future, so a later zstd/x-lz4 response is handed to JsonParserIterator still compressed and parsing fails. Defer the encoding lookup until the future completes, e.g. always transform with a function that reads the AtomicReference after handleResponse has set it.
| if (acceptEncoding == null) { | ||
| return null; | ||
| } | ||
| if (acceptEncoding.contains("zstd")) { |
There was a problem hiding this comment.
[P2] Honor q=0 when negotiating encodings
This substring check treats headers like gzip, zstd;q=0 or x-lz4;q=0 as accepting the encoding, then sends a compressed response that the client explicitly marked unacceptable. QueryResultPusher handles user-facing query responses too, so this can break standards-compliant clients. Parse Accept-Encoding as tokens with q-values and only select zstd/x-lz4 when q is absent or greater than zero.
Fixes #XXXX.
Description
Fixed the bug ...
Renamed the class ...
Added a forbidden-apis entry ...
Release note
Key changed/added classes in this PR
MyFooOurBarTheirBazThis PR has: