W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] New URL Standard

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 25 Sep 2012 22:15:53 -0500
Message-ID: <CABirCh_ShHMTUBXsX8NpTZUHWk-gCQYDMnzOS8Dgbi1EQqdmvg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC