Bug 204127 – Inconsistent/lazy encoding of URL.searchParams

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore JavaScript

[Jim Heising]

DESCRIPTION:

When a window.URL object is created with a URL string that contains search params with non-url-safe characters, they will only be properly encoded after a call is made to any method on the searchParams member.

It seems like encoding of search parameters is done lazily, when it should probably be done at object construction time.

EXAMPLE:

> var myURL = new URL("https://test.com?param1=my{{bad}}param");
> console.log(myURL.toString());
> // Output: https://test.com/?param1=my{{bad}}param
> // Note how param1 is not properly encoded
>
> myURL.searchParams.sort(); // Doesn't seem matter what method is called— we choose sort here...
> console.log(myURL.toString());
> // Output: https://test.com/?param1=my%7B%7Bbad%7D%7Dparam
> // Note how param1 is now properly encoded

[Jim Heising]

It seems like one solution would be to call updateURL() (https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/html/URLSearchParams.cpp#L139) during object construction.

[Radar WebKit Bug Importer]

<rdar://problem/57251311>

[Alex Christensen]

Our behavior here matches the behavior of Chrome and Firefox and the URL specification.  For whatever reason, https://url.spec.whatwg.org/#concept-urlencoded-byte-serializer uses a different set than https://url.spec.whatwg.org/#query-state step 5.  Because the behavior of all browsers agrees, you're going to have a hard time changing the specification.