Bug fixed: Proxy did not pass query string to target

tl;dr: Whenever a site had a proxy redirect rule - a rule with status 200 pointing to a third-party host - the query string would not be passed in the request. We fixed that.

The Feature

In the docs: https://docs.netlify.com/routing/redirects/rewrites-proxies/#proxy-to-another-service

We allow rules in the _redirects file or netlify.toml to point to origins other than your site.
This is useful for redirecting to external sites.
If you specify a status code of 200 on the rule, our webserver will not redirect the request, but behave like a reverse-proxy to that host.

This is useful for:

  • Using APIs that cannot provide CORS
  • Integrating (and caching) external data sources
  • Improving load times by making the request go through our CDN
  • Advanced integration logic, like authenticating with JWT in the CDN layer

The Bug

For a long time the proxy was configured in a way that it would ignore any query string that was not explicitly stated in the url to proxy to.
This had effects on APIs that are using query arguments for pagination or specifying a query on data.

The Solution

The proxy logic will now always pass the query string from the client request unchanged to the proxies host.
The only exception: If your rule target already contains a query string, the proxy will only pass that along, nothing else.

Examples:

  • /api/* https://my.remote.api/:splat 200! will pass query string unchanged
  • /api/* https://my.remote.api/:splat?key=secret-key 200! will only ever pass key=secret-key

If you have been affected, Iā€™d be glad to hear whether our solution works for you.

Note about the rollout:

  • This has only been applied to the regular (non-enterprise) CDN
  • We will apply this to the enterprise CDN once we verified the fix with non-enterprise customers
5 Likes