Search jQuery

jQuery Forum

Developing jQuery Core

douglasbtx

Should null be passed in query strings generated by jQuery.param?

in Developing jQuery Core • 11 years ago

Currently,

jQuery.param({"foo":null})

returns

"foo=null"

On the server, this gets treated as the string "null", even though a string was not passed in.

I think that it would be a good idea to return this instead:

"foo="

which is at least closer to null.

The patch would be to change

s[ s.length ] = encodeURIComponent( key ) + "=" + encodeURIComponent( value );

into

s[ s.length ] = encodeURIComponent( key ) + "=" + encodeURIComponent( value === null ? "" : value );

Replies(9)

dave.meth..

Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

This isn't really a case that serialize() could be expected to handle since in an HTML form there is no case where a successful control would have a null or undefined value. In other words, I think it's a programming error to do this. But if we're going to "correct" developer mistakes and read minds, why not handle foo: undefined as well for example? Was there a reason to use === instead of == there?

marcusjt

Re: Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

I agree with your point about successful controls via the HTML spec, and there's no problem with normal form serialization.

The problem is that (as in the cited example) a parameter with a null value can become a parameter with a string "null" value, which is very different indeed, and surely must cause problems for developers in a variety of scenarios (though admittedly it's baffling why this hasn't been reported before now).

At present in order to mitigate this issue developers must either (1) wrap code around the call to .param() to strip out null variables OR (2) code their back-end scripts to accept parameters with "null" string values.

Reworking the code to incorporate a checks for null (as in the first post) and undefined (as you suggested) would effortlessly address case (1) for all developers, which is surely desirable.

However, doing so may potentially affect existing instances of case (2) so I suggest that this auto-corrective behaviour should disabled by default and enabled either via an optional parameter to .param() or via a global jQuery configuration parameter.

dave.meth..

Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

I'm not opposed to making this change, and technically it should not affect anyone since the current behavior isn't something that anyone should be depending upon. Of course we often find out that there is a lot of undocumented behavior that people exploit, which is often reason enough to avoid making a change. It seems to me that items with a value of null or undefined should not appear in the serialization at all, is there a reason why you'd want them coerced to an empty string? In a JSON serialization for example, undefined entries don't appear. But this is why a seemingly simple request is harder to implement than you might think.

Can you create a ticket for this suggestion at bugs.jquery.com and reference this thread? That way we can get it tracked and make a decision on it.

I definitely not in favor of creating some flag that lets people select the old or new behavior. We did that with the ajaxSettings.traditional flag and I think it was a mistake. In that case the new behavior was the default, which is what I suspect you are recommending here. So some old code broke until users went in and changed their code to flip the traditional flag. Even if we do it the other way around it just complicates the code and documentation; it becomes more straightforward for the few people who need the exceptional behavior to do it themselves, rather than push the burden onto everyone.

marcusjt

Re: Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

Dave - I did say...

I suggest that this auto-corrective behaviour should disabled by default

(i.e. that the new behaviour should be off unless deliberately enabled), but this does mean that it wouldn't actually help anyone encountering the issue until they discovered that there was an optional fix...

I also take your point that offering a choice for such an subtle thing adds unnecessary complexity so it would be preferable for it to work only one way...

And finally, I agree that it would be better for null and undefined parameters to not be serialized at all, instead of making them have no value as was originally proposed.

Douglas - Is that workable for you?

douglasbtx

Re: Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

I ran into this while calling Asp.net WebMethods using jQuery.ajax. The query string for these requests gets generated by the output from jQuery.param(options.data), where options is the object passed into jQuery.ajax.

Asp.net WebMethods are simply methods on a class with a [WebMethod] attribute. When the web server receives the request, it uses the path component from the url to select the class, and the path plus the query string keys to work out which method to call. The keys from the query string are matched against the argument names of the methods, so if a key is missing the web request will fail due to not being able to find the correct WebMethod. I imagine that other frameworks might use the same abstraction.

So, stripping keys with null values would be a breaking change for me.

The code I an working on previously used the ajax wrapper from the Prototype library, here's the output it produces:

Object.toQueryString({
"alpha":"value",
"null":null,
"undefined":undefined,
"beta":"value"});
==>
"alpha=value&null=&undefined&beta=value"

Null values are treated as empty string, and undefined values are sent by key only, with no "=".

This is more subtle behaviour than I suggested above, what do you think?

Kevin B

Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

something about this just isn't clicking with me...

In your example, you set foo equal to null, and you have a problem with null being passed as a url value.

I don't see how this is a problem. foo is null, so it passes null. if it was undefined, it would pass undefined. if it was an empty string, it would pass an empty string. where is the issue?

Should jQuery.param() be automagically reassigning the values that you are passing into it?

If I wanted jQuery.param() to return an empty string for a value, i would pass that value as an empty string, not null or undefined.

Edit: In the end though i dont think a change like this would affect very many people. how many times do you use .param() on something other than form elements? i personally haven't come across this scenario before.

-- Kevin

dave.meth..

Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

Marcus, clearly I am not a very good reader. :)

I think the question is whether serializing a null or undefined value should yield a "null" or "undefined" string if it somehow exists in the input to serialize().

marcusjt

Re: Re: Should null be passed in query strings generated by jQuery.param?

11 years ago

the question is whether serializing a null or undefined value should yield a "null" or "undefined" string
if it somehow exists in the input to serialize().

It's perhaps useful to adapt that question a little and ask in what scenarios it would actually be useful to end up with "null" or "undefined" string values in a querystring or form POST data, and I can't think of any justification for
either, nor why one would want to differentiate between those two subtlety different values in server-side code.

However, if we're talking about serialization to JSON, then of course it does make sense to preserve such subtleties so
that they can be restored when the JSON is deserialized.

EDIT: That's odd, I had the same overlong line issue that you had, so have had to manually add linebreaks,

I wonder what's causing that?!

douglasbtx