Change to handling encoded parameters in 7.0.2

[shank-eric]

Hello!

I recently upgraded from 7.0.1 to 7.0.2 and had a test fail due to a change in how encoded URL parameters are handled. For example, with 7.0.1 when I pass a URL like http://test.com?encodedParam=foo%2Fbar%2Fbaz into sanitizeUrl I get back http://test.com?encodedParam=foo%2Fbar%2Fbaz.

But with 7.0.2 when passing the same URL in, I now get back http://test.com?encodedParam=foo/bar/baz. I've created a little sample code sandbox here: https://codesandbox.io/p/sandbox/little-butterfly-4n6xzp?file=%2Fpackage.json%3A10%2C38. You can see the change in behavior by switching the version in the package.json in that sandbox.

I've reverted to 7.0.1 for now, but Is this an intended change?

[animeshk874]

I've been facing something similar too. Might be related to this change here - https://github.com/braintree/sanitize-url/commit/6c15df9c76ed28efcca894c7c51510cae5af3fd8

[ibooker]

Hello, Thanks for reporting this issue. We'll take a look.

(internal tracking BTWEB-173)

[M0ns1gn0r]

I am experiencing the same issue. I see 7.1.0 was released without fixing this breaking change.

[jviolas]

I have the same issue with some URI encoded characters (especially for + as %2B and % as %25). And it's not only query parameter, it affects also the path of the url. If you put https://example.com/path/with/100%25.png, it will output https://example.com/path/with/100%.png which is not uri encoded, and will fail if passed to decodeURI() because there is a % without a hexacode behind it. This behavior has changed since #73 because now the input url goes through decodeURIComponent() but are not re-encoded after. Only some of them are when using URL.toString() at the end.

[eunicocornelius]

+1 to this, I am also facing this same issue, in 7.1.0. It would be great to have an additional parameter to choose whether to decode the URL or not instead like sanitizeURL(url, decode=true/false)

[terrance456]

Hi any update? Running into same issue in 7.1.0.

[te-online]

Same issue here. It's very hard to work around, because the initial URL input may or may not be (partly) URL encoded, making it impossible to decide whether to decode after sanitizing...