Re: [whatwg/url] URLSearchParams inconsistent behavior with multiple same-name parameters leads to data loss on backend (Issue #889)

Voral left a comment (whatwg/url#889)

Thank you for your response. I understand your position that the flaw may lie with the backends. However, I would like to explain why this issue is not about a theoretical specification mismatch, but rather about the most natural workflow for millions of developers.

**Please accept my apologies for not noticing the similar ticket #851 you mentioned** when I created this issue.

I have been working in web development since 2003, and throughout this time, the **Apache/Nginx + PHP + HTML forms** stack has been and remains one of the most common in the history of the internet. This is not some "incorrect" or niche configuration—it is the foundation a huge part of the web is built upon.

When I saw `URLSearchParams` in JavaScript, I was pleased: finally, a native, convenient tool for working with form data and query strings that could replace manual string manipulation. Specifically, the `.append()` method directly suggests the ability to work with multiple values, just like HTML forms with `<select multiple>` or groups of checkboxes do.

**Here is the core problem:** This tool appears to be the perfect solution for a standard task (sending form data via `fetch` or `XMLHttpRequest`), but in practice, it turns out to be a **"footgun"**. A developer, relying on the intuitive API, unexpectedly faces silent and hard-to-debug data loss on the backend.

Regarding popular libraries—yes, all common HTTP clients (jQuery.ajax, Axios, etc.) solve this problem under the hood. They either use the PHP-style with `[]` or serialize arrays in their own way. The fact that these libraries had to implement their own logic on top of the native API already speaks to its inadequacy for real-world tasks.

**It's worth noting that PHP adopted its array handling behavior (with `[]` brackets) about 20 years earlier, if I'm not mistaken.** This created a de facto standard that predates the formal specification.

**In essence, the current `URLSearchParams` creates a disconnect between:**
*   **Expectation:** "A convenient native API for working with form data."
*   **Reality:** "A tool that works correctly only with backends that follow a pure, but less common, interpretation of the standard."

My proposal is not a demand to break backward compatibility, but an attempt to **reconcile the standard with reality**. Adding an optional parameter (`groupMultiple` or `arrayFormat`) would allow us to use this excellent tool for its intended purpose—seamless work with typical backends—without harming existing code.

In the end, as a developer, I've encountered a situation where a native API does not solve my everyday task, and this is disappointing. Naturally, if this functionality is not implemented, I, like many others, will simply avoid using `URLSearchParams` for working with multiple values and will continue to write workarounds. But I believed the goal of standards was to provide us with the very tools that save us from having to write such workarounds.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/889#issuecomment-3461763882
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/889/3461763882@github.com>