feat(requester-node-http): add gzip compression for requests and response decompression #1603
+268
−18
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…onse decompression When the accept-encoding header includes gzip, request bodies are compressed with zlib.gzipSync() and a content-encoding: gzip header is added. Responses with content-encoding: gzip are decompressed via zlib.createGunzip(). Decompression errors resolve gracefully following the existing error handling pattern (never reject). Includes 8 comprehensive tests covering compression, decompression, error handling, multi-value headers, and full round-trip scenarios.
Ant-hem
reviewed
Feb 6, 2026
Ant-hem
reviewed
Feb 9, 2026
Use Buffer.byteLength() to set content-length for both compressed and uncompressed request bodies, avoiding unnecessary chunked transfer encoding overhead.
Small request bodies gain little from compression and the gzip overhead can exceed the savings. Only compress when body size >= 1024 bytes.
Release the native zlib handle promptly instead of waiting for garbage collection. Covers both the error path (decompression failure, response stream error) and the timeout path (req.abort mid-transfer).
samouss
reviewed
Feb 9, 2026
Comment on lines
+109
to
+111
| gunzip.on('data', onData); | ||
| gunzip.on('end', onEnd); | ||
| gunzip.on('error', onError); |
There was a problem hiding this comment.
I'm a bit rusty in JavaScript so please disregard if not relevant: Why do we have to listen on the gzip object AND the response? We pipe the gzip object on the response so why don't we listen once on the response instead of branching?
|
|
||
| if (request.data !== undefined) { | ||
| req.write(request.data); | ||
| const body = shouldCompress ? zlib.gzipSync(request.data) : request.data; |
There was a problem hiding this comment.
Is it really safe to use the sync API in this context? If used in the server side, the requests can be pretty large (multiple MB) so we should probably avoid blocking. I would rather go with the async approach.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the accept-encoding header includes gzip, request bodies are compressed with zlib.gzipSync() and a content-encoding: gzip header is added. Responses with content-encoding: gzip are decompressed via zlib.createGunzip(). Decompression errors resolve gracefully following the existing error handling pattern (never reject).
Includes 8 comprehensive tests covering compression, decompression, error handling, multi-value headers, and full round-trip scenarios.