- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 25 Sep 2012 22:15:53 -0500
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg@lists.whatwg.org
On Tue, Sep 25, 2012 at 9:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 9/25/12 10:36 PM, Glenn Maynard wrote: > >> You usually don't care about the resulting order in that case, right? >> > > It's not uncommon for servers to depend on a particular order of > parameters in the query string and totally fail when the ordering is > different. Especially the sort of servers that have a .exe for their CGI > instead of using an off-the-shelf CGI library. > > > When do you care about being able to specifically create (or >> distinguish) "a=1&b=2" vs. "b=2&a=1" >> > > Whenever the server will barf on one of them? ;) > It's easy enough to allow creating a specific ordering of individual items, by guaranteeing that when a key is assigned to the object, if that key didn't already exist in the query, it will be added to the end. That means you can say url.query.x = '1'; url.query.y = '2'; vs. url.query.y = '2'; url.query.x = '1'; to create "x=1&y=2" and "y=2&x=1", respectively. That's the behavior I'd expect anyway. (If the key already existed, it should replace it in its previous position, of course, not bump it to the end.) What this doesn't allow is creating things like "a=1&b=2&a=3". You can create "a=1&a=2&b=3" (url.query.a = ["1","2"]; url.query.b = "3"), but there's no way to split the keys (a, b, a). This is the limitation we were really talking about. This seems unlikely to be a real problem, and in the unlikely case where it's really needed, it seems fine to require people to just fall back on formatting the query string themselves and assign to url.search. -- Glenn Maynard
Received on Wednesday, 26 September 2012 03:16:23 UTC