Existing encoding of url query parameters is being rewritten

[sreuter]

Bug Description

#497 added support to skip the encoding of certain characters via the skipEncodingChars option.

This at first glance looked promising to use, as we were running into an issue where we had to ensure an = is not being encoded. It only solved half of our issues though.

It turns out that the API that we're talking to (Cloudinary) is even pickier about the encoding of the parameters, as it only accepts lower-cased encodings, e.g. %2f instead of %2F.

But when we provide a url with query parameters like this ?__cld_token__=exp=1657025954~acl=%2f*%2fauthenticated%2fa2fd268b-ac62-4473-b906-8d28dd163e9a%2f*~hmac=XXXXXXXX, z.request changes all occurrences of %2f to %2F which causes the request to fail.

I personally feel like a cleaner solution to having a list of characters to exclude from encoding, is simply to add a flag that will allow keeping query parameters already provided on the URL untouched.

Reproduction Steps

Make a request like this:

 const fileRequest = z.request({
    url: `https://test.com?___token___=path=%2ftest%2f`,
    raw: true,
    skipEncodingChars: "=",
  } as any);

You'll see that the query string is being changed to ___token___=path=%2Ftest%2F.

Version Info

• Version info:

• CLI version: 12.0.2
• Node.js version: v16.14.0
• OS info: darwin-arm64
• zapier-platform-core dependency: 12.0.3

• Operating System: OSX

• App id: 127170

[sreuter]

@xavdid, as you've added the existing flag, maybe you know a workaround we could make use of?

[sreuter]

Quick update: we figured that we can just use node-fetch directly as an escape hatch for the time being. I'll leave this open though as I think this is still a valid concern to address at some point though.