pass through compressed content in hosting proxy #3065
Merged
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.
Description
When using the Hosting emulator, we insert middleware for two cases:
In both of these cases, we send along most of the original request through
node-fetch
and receive a response. Now,node-fetch
(in apiv2) "helpfully" will automatically decompress the response if it is a recognized compression (viacontent-encoding
headers) and return to our proxy logic the decompressed content. When we take that response and pass it (along with the original headers) along to the originating response, we sometimes lose content because the compressed response is not re-compressed automatically and thecontent-length
header can cause the response to look truncated.This PR adds support for the
compress
flag, which originates fromnode-fetch
. Thecompress
flag indicates toapiv2
(andnode-fetch
) that it (a) should not add anaccept-encoding
header to the response if one does not exist and (b) should not decompress the response if it recognizes the encoding. With that in place, our proxies correctly return compressed content as appropriate and the requests don't throw errors in browsers any longer.Fixes #3052
Fixes #3055
Scenarios Tested
I was able to replicate this behavior fairly reliably for (1) by initializing a new Hosting directory and loading it up in the emulator. Looking at the network tab of the inspector, I see no more "failed" responses.
#3055 provided a repro case that I was able to use for (2). Their
/test
endpoint would fail to load, but with this fix, it is successfully loading again.I also added a test that verifies that the middleware powering (1) doesn't decompress the request when it's being proxied. This was slightly tricky to write because I have to use more basic Node tools, but I believe the test to be valid (and it breaks if
compress
is removed).I guess this goes into the pile of "things
request
used to do automatically". This was a bugger to track down, but I feel more confident in it now.