feat: add decompress interceptor #3274
Conversation
adrianfalleiro
force-pushed
the
feat/decompress-interceptor
branch
from
938fa4b
to
df4804c
Compare
|
Should we also handle rawdeflate? |
Yep, I'm using the existing |
Co-authored-by: Robert Nagy <ronagy@icloud.com>
lib/interceptor/decompress.js
Outdated
| this.#inputStream, | ||
| ...restDecoders, | ||
| this.#onDecompressStreamFinished.bind(this) | ||
| ).on('data', (chunk) => this.#handler.onData(chunk)) |
| } | ||
| } | ||
|
|
||
| function createDecompressionInterceptor () { |
There was a problem hiding this comment.
We might need to support add the hinting of supported encoding in case implementers wants to limit this (I can only think for performance reasons).
They can pass a set of encodings supported, and the decompress decorator hints it using accept-encoding
| outputStream.on('data', (chunk) => { | ||
| if (!this.#handler.onData(chunk)) { | ||
| this.#inputStream.pause() | ||
| this.#inputStream.once('drain', () => this.#inputStream.resume()) |
There was a problem hiding this comment.
Those is wrong. Drain is signaled through the resume function sent to onHeaders
| // https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding | ||
| if (requestEncodings.length !== 0 && method !== 'HEAD' && method !== 'CONNECT' && !nullBodyStatus.includes(statusCode)) { | ||
| const decoders = [] | ||
| for (let i = 0; i < requestEncodings.length; ++i) { |
There was a problem hiding this comment.
| for (let i = 0; i < requestEncodings.length; ++i) { | |
| for (let i = requestEncodings.length - 1; i >= 0; --i) { |
There was a problem hiding this comment.
The other way round, right?
There was a problem hiding this comment.
Yeah, I made the same changes #3343.
There was a problem hiding this comment.
Thanks, I'll come back to this PR this week
| } | ||
| } | ||
|
|
||
| return this.#handler.onHeaders( |
There was a problem hiding this comment.
Thanks for putting up this pr! I added this interceptor into my project.
This interceptor could also be used with fetch if you remove the content-encoding. My use case is I have a LoggingInterceptor that sends the response body to GCP logging. This worked great except one API sends a gzipped response. Now I have the following flow:
Decompress -> Logging -> Fetch
delete parsedHeaders['content-encoding'];
const newRawHeaders = Object.entries(parsedHeaders)
.flat()
.map((e) => Buffer.from(e));
return this.#handler.onHeaders(statusCode, newRawHeaders, resume, statusMessage);There was a problem hiding this comment.
Welp - I ended up having issues with the interceptor. Haven't been able to dive in yet, but I feel like my flow should work. Will try again once this is reviewed/merged.
Added a new interceptor to decompress the response body. I lifted some of the implementation from the way decompression is handled in the fetch client
This relates to...
Rationale
Changes
Features
Bug Fixes
Breaking Changes and Deprecations
Status