fix: Remove content-encoding header from already decompressed responses

[benbrandt]

When the compress flag is set to true, the fetch implementation sends an Accept-Encoding header and decompresses the response.

However, the decompressed body is put into a Response that still has a Content-Encoding that no longer matches the actual encoding of the body.

This causes issues if this Response object is used downstream (i.e. sent back to a browser), and there is another attempt to decode the body based on the content-encoding header.

[changeset-bot]

🦋 Changeset detected

Latest commit: 894adcb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@remix-run/web-fetch	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benbrandt]

@brophdawg11 does this change make sense? Or is there more I need to do around the changeset to get this ready for review?

[jacob-ebey]

@benbrandt This behavior is unspecified by the spec as far as I can tell, and there is open discussion happening here around the topic here: wintercg/fetch#23

This makes sense to me though and I'm happy to get this merged to generally ease the use of fetch in a server environment.

[benbrandt]

@jacob-ebey thanks for the link. Definitely not a straightforward topic by any means. Happy to see it merged if it makes sense on your end. Thanks for the help!

[jacob-ebey]

I'm going to do some spec reading and exploration, but I'm having second thoughts on this.... We (remix's fetch polyfill) used to recommend decoding and passing on the relevant data in the docs at some point, or returning a raw object from fetch().then(r => r.json()) to get around this. The previous recommendations are spec compliant and this is potentially not if a decision is made to define this behavior. The root of this concern isn't directly related to what this enables, but rather an underlying "is fetch() capable of xyz" where the xyz is "consume a raw compressed body for further processing".

I want others to weigh in here.