[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pass through compressed content in hosting proxy #3065

Merged
merged 2 commits into from
Jan 21, 2021
Merged

Conversation

bkendall
Copy link
Contributor

Description

When using the Hosting emulator, we insert middleware for two cases:

  1. fetching javascript SDK files from gstatic and providing initialization helpers, and
  2. proxying to CF3, either locally emulated functions or live functions.

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 (via content-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 the content-length header can cause the response to look truncated.

This PR adds support for the compress flag, which originates from node-fetch. The compress flag indicates to apiv2 (and node-fetch) that it (a) should not add an accept-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.

@bkendall bkendall added the cleanup: request PRs for removing the request module from the CLI label Jan 20, 2021
@google-cla google-cla bot added the cla: yes Manual indication that this has passed CLA. label Jan 20, 2021
@clintecker
Copy link

Just want to say thank you for this, I was running down this bug myself in hosting rewrites to callable functions that began affecting us a couple days ago. 👍

@bkendall bkendall merged commit a9eb22e into master Jan 21, 2021
@bkendall bkendall deleted the bk-compress branch January 21, 2021 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Manual indication that this has passed CLA. cleanup: request PRs for removing the request module from the CLI
Projects
None yet
5 participants