Error upon receiving a compressed response.

[JustinTRoss]

When you pass "Accept-Encoding" header to a supporting endpoint, and it responds with compressed data, it errors during json parse, here.

I'm having trouble finding a mechanism to decorate with this decompression. Any suggestion?

[StarpTech]

Hi @JustinTRoss, you should not pass this header but to support this use case we could check if the endpoint responds with a "Content-Encoding" header. If the response was compressed, we skip JSON parsing and pass the content as it is. Would you like to create a PR?

[JustinTRoss]

When you say, "you should not pass this header", do you mean "passing that header is not currently supported", or "passing that header is generally a bad practice" ? 😅

You suggestion could work. I figure we'd just switch on Content-Encoding and decode as appropriate, like so: nodejs/undici#1155 (comment)

[StarpTech]

I mean it is not supported. I'm not sure if it is a good idea to make this lib responsible for decompressing. It should be enough to get access to the raw body.

[JustinTRoss]

Got it. What gives you pause about doing so? Thinking through where we could handle compression, here are the thoughts that lead me to identify this as the place to handle it:

• Other http clients handle decompression by default, making it the expectation here.
• Handling decompression client-side would require duplicated low-level response handling for every call or creating a wrapper over this lib.
• Returning the raw body would be the first such leakage of implementation detail of using Undici. It would require consumers understand and interact with Undici, which seems undesirable to me. Alternatively, we could return something like body.text(), but this would incur an unnecessary performance hit of stream -> blob -> text before -> stream -> json.

Something that may mitigate worry is to provide an escape hatch to communicate desire to prevent decompression, similar to what is used for fetch:

fetch(url, {
    compress: false,
    headers: { "accept-encoding": "gzip" },
});

[StarpTech]

I see your points and I agree with most of them but this library isn't a general-purpose HTTP client. It was developed for internal communication. Just for clarification. You request compression support right? If your API compresses content by default this is a violation of the protocol.

If you create a PR that adds compression support similar to

You suggestion could work. I figure we'd just switch on Content-Encoding and decode as appropriate, like so: nodejs/undici#1155 (comment)

I'd be happy to review it. Please have in mind that this library is optimized for performance. Requests that don't require decompression should not be impacted by any means.

[JustinTRoss]

Got it. Makes sense. Yes, compression was requested 😅 .

Definitely agreed regarding not impacting requests without a requirement for compression.

@jsudhakar-gdrx opened a PR that achieve this end. 🎉