feat: add support for compressing Response objects from Fetch API #363
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
…cannot Sending something other than buffers of strings in the `payload` happens, but this would break the later `Buffer.byteLength(payload)` Signed-off-by: Bart Riepe <[email protected]>
- Add Response object detection in isCompressiblePayload - Implement convertResponseToStream helper to extract body from Response objects - Handle Response headers and status code preservation in both onSend hook and reply.compress() - Add comprehensive tests for Response object compression scenarios Closes fastify#309 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
…ypes - Add tests using actual Fastify server with real HTTP requests - Test with both fetch and axios to ensure compatibility - Verify compression works for all supported types: - JSON objects - Plain strings - Buffers - Node.js Readable Streams - Response objects - Raw ReadableStreams - Test edge cases like empty responses and large streams - Ensure clients receive correct decompressed data
- Add got as a third HTTP client to test alongside fetch and axios - Got preserves content-encoding header after decompression, providing an additional verification that compression is working correctly - All 36 tests pass with got, confirming compatibility
When handling Response objects from the Fetch API, the compress middleware now copies headers and status code from the Response to the reply, unless those headers have already been explicitly set on the reply. This provides more intuitive behavior - if someone returns a Response object with specific headers (like content-type, cache-control, etc.), those headers will be preserved in the final response. - Headers already set on the reply take precedence over Response headers - Status code is copied only if reply still has default 200 status - Added comprehensive tests to verify header handling behavior - Updated README to document this behavior
6 tasks
mcollina
reviewed
Jul 1, 2025
|
|
||
| interface FastifyReply { | ||
| compress(input: Stream | Input): void; | ||
| compress(input: Stream | Input | Response | ReadableStream): void; |
There was a problem hiding this comment.
This needs a type test as well.
jsumners
reviewed
Jul 2, 2025
mcollina
requested changes
Jul 2, 2025
| @@ -0,0 +1,544 @@ | |||
| 'use strict' | |||
There was a problem hiding this comment.
How does this relates to this PR?
| }) | ||
| } | ||
|
|
||
| test('It should not compress non-buffer/non-string payloads', async (t) => { |
There was a problem hiding this comment.
the test description does not match what is being tested
| t.assert.equal(decompressed, responseBody) | ||
| }) | ||
|
|
||
| test('It should compress Response objects using reply.compress()', async (t) => { |
There was a problem hiding this comment.
how is this different from the previous test?
|
|
||
| fastify.get('/', (_request, reply) => { | ||
| reply.header('content-type', 'application/json') | ||
| reply.send(readableStream) |
There was a problem hiding this comment.
please just use a ReadableStream object, without passing through Response
| t.assert.equal(decompressed, responseBody) | ||
| }) | ||
|
|
||
| test('It should compress ReadableStream objects using reply.compress()', async (t) => { |
There was a problem hiding this comment.
how is this different from the previous test?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
After I made the other PR's, I realized there was already an issue open for this, and so I've made an attempt to make a more comprehensive fix to the supported types using Claude Code. It all seems proper to me, and both the new and old tests pass, but still, it's mostly LLM work, so discretion is adviced.
If this is merged, there is no need for #361
Summary
Details
This PR addresses issue #309 by implementing proper handling of Response objects and ReadableStream
objects in fastify-compress.
Key Changes:
Extended payload type support:
isCompressiblePayloadto detect these new typesStream conversion:
convertResponseToStreamhelper that extracts the body from Response objectsReadable.fromWeb()to convert Web Streams to Node.js streamsFocused middleware behavior:
Content-Encoding,Vary)Documentation updates:
reply.compress()examples with Response and ReadableStream usageTypeScript support:
Response | ReadableStreamin compress methodTests added
Breaking Changes
None - this is a backwards-compatible enhancement.
Closes #309
🤖 Generated with Claude Code