QueryString.stringify and request parameters

[Thomas Lee]

Hi all,

I'm just curious why QueryString.stringify() adds square brackets to parameters with array values?

e.g. QueryString.stringify({a: ["1", "2", "3"]}) produces "a%5B%5D=1&a%5B%5D=2&a%5B%5D=3" (where %5B%5D is url encoded square braces)

While I'm aware other languages & frameworks use this style, it seems redundant and unnecessary here. Node's http server implementation (as of 1.30 anyway) seems to be able to handle multiple values without the square brackets just fine e.g. a=1&a=2&a=3 ... so why are the square braces being added here? Is there a good reason for doing this?

Cheers,
Tom

[Isaac Schlueter]

Tom,

The rationale is that, if you want to serialize an object to a query
string, odds are you're not making a request to a node server, but
rather to some other kind of server, which might be running php, perl,
python, or ruby.

In fact, there's been some requests in the past to *not* support
a=1&a=2 as an array, but instead do a "last one wins" just like ruby
and php. In my opinion, that's unnecessary and dumb, and thankfully,
it seems like everyone is getting by just fine without that behavior.

I hate that php and ruby use a[]=1&a[]=2. It's ugly and stupid. It
broke my heart to write querystring.stringify that way, but at the
time, I was writing it as part of a client-side library that was
talking to a php server, so I had no choice.

Right or wrong, it's the de facto standard. If you're stringifying an
object, it's best to assume that you're doing so for some other
implementation that may depend on that.

--i

> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
>

[Thomas Lee]

Hi Isaac,

Thanks for the speedy response.

Our situation is the reverse: we're talking to a system that *doesn't* support the param[] syntax. Any chance of an option to enable/disable this behaviour at the caller's behest? Happy to provide a patch if you're strapped for time.

Otherwise we're going to have to copy & paste QueryString.stringify specifically to disable this behaviour, which is something we'd obviously like to avoid!

Cheers,
Tom

[Isaac Schlueter]

As long as Ryan's ok with accepting the change, I'd be happy to review
the patch.

I'd suggest just ditching the [] altogether. If you want to talk to a
PHP server, you can always just abuse your object keys with cruft if
you really want to.

--i

[Thomas Lee]

Sure thing, I'll put together an initial patch.

Before I do that though, what are your thoughts on handling object parameter values? e.g.

{foo: {bar: "baz"}}

Would be stringified as:

foo[bar]=baz

Do you think we should disallow this sort of thing? It would play havoc with taking the current treatment of arrays out of the picture. For example:

{foo: [{bar: "baz"}]}

Stringified:

foo[][bar]=baz

If we take away the special treatment of arrays, we wind up with:

foo[bar]=baz

Which is obviously a bit ambiguous given the input.

Perhaps the current stringify() implementation could be renamed to serialize() or something, and we'll implement stringify assuming only strings and arrays for values? Or we could provide a "serialize" option for stringify(), or provide an entirely different function ... although I can't think of a particularly good name for it that would really distinguish it from stringify :)

Cheers,
Tom

[Thomas Lee]

To clarify, whatever the final solution is, all that matters to us is that we can pass through multiple values for the same parameter without the parameter names getting mangled.

Cheers,
Tom

[r...@tinyclouds.org]

On Wed, Apr 14, 2010 at 9:52 PM, Isaac Schlueter <i...@izs.me> wrote:
> As long as Ryan's ok with accepting the change, I'd be happy to review
> the patch.
>
> I'd suggest just ditching the [] altogether.  If you want to talk to a
> PHP server, you can always just abuse your object keys with cruft if
> you really want to.

I'm okay with it

[Scott González]

This seems like a strange decision to make. With HTTP being such an important part of node, why would we choose to make it difficult to support the majority of web sites? I would prefer having native support for both methods, with a flag for which one to use, defaulting to the current implementation.

--

[Aaron Heckmann]

That's exactly what jQuery did a few months back. They decided to support both but have a flag available to toggle methods.

2010/4/15 Scott González <scott.g...@gmail.com>

--
Aaron

[Thomas Lee]

If that's the consensus, I'm happy to implement the patch as an option passed to stringify/parse.

Isaac, would you be happy enough to see this implemented as a flag? Perhaps an options hash in place of the current parameters for stringify/parse, including an option for "compatibility mode"? I imagine quite a few folks would feel pretty strongly about the PHP-style params going away, however nasty they are.

Cheers,
Tom

Thomas Lee
Consultant
Ph 03 8622 1900 Fax 03 9600 1805

Level 34, 385 Bourke Street, Melbourne VIC 3000

a passion for excellence
www.shinetech.com

This email is intended solely for the use of the addressee and may contain information that is confidential or privileged. If you receive this email in error please notify the sender and delete the email immediately.

[r...@tinyclouds.org]

>> On Wed, Apr 14, 2010 at 9:52 PM, Isaac Schlueter <i...@izs.me> wrote:
>> > As long as Ryan's ok with accepting the change, I'd be happy to review
>> > the patch.
>> >
>> > I'd suggest just ditching the [] altogether.  If you want to talk to a
>> > PHP server, you can always just abuse your object keys with cruft if
>> > you really want to.

> On Thu, Apr 15, 2010 at 1:44 AM, <r...@tinyclouds.org> wrote:
>> I'm okay with it

2010/4/15 Scott González <scott.g...@gmail.com>:

> This seems like a strange decision to make. With HTTP being such an
> important part of node, why would we choose to make it difficult to support
> the majority of web sites? I would prefer having native support for both
> methods, with a flag for which one to use, defaulting to the current
> implementation.

I meant that I'm okay with a patch to support it.

[Thomas Lee]

Cool. Will do that then.

Cheers,
Tom

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

--
Thomas Lee
Consultant
Ph 03 8622 1900 Fax 03 9600 1805

Level 34, 385 Bourke Street, Melbourne VIC 3000

a passion for excellence
www.shinetech.com

This email is intended solely for the use of the addressee and may contain information that is confidential or privileged. If you receive this email in error please notify the sender and delete the email immediately.