Bug Tracker

Opened 14 years ago

Closed 12 years ago

Last modified 9 years ago

#3400 closed enhancement (wontfix)

Encoding of spaces in Ajax requests should be configurable

Reported by: sdeitmer Owned by: john
Priority: minor Milestone: 1.3
Component: ajax Version: 1.2.6
Keywords: ajax uri encoding space Cc:
Blocked by: Blocking:


The current implementation of jQuery.param() uses JavaScript's encodeURIComponent() to encode parameters, but then replaces all instances of "%20" with the "+" character. This doesn't work with the Axis2 framework (REST endpoints), for example, which doesn't decode "+" back to space characters. It also makes it impossible to distinguish between actual "+" characters and encoded space characters.

I simply removed the replacement action described above, so that spaces are always encoded as "%20", but I'm sure the replacing is being done for a reason, so maybe this could be made configurable?

Change History (15)

comment:1 Changed 14 years ago by flesler

Owner: set to joern

I think Joern was the one that implemented that replacement, will ask him.

comment:2 Changed 14 years ago by joern

Owner: changed from joern to john

John changed that as part of [3115].

comment:3 Changed 14 years ago by ecmanaut

Please remove the .replace(/%20/g, "+") from jQuery.param -- if it was the right thing to do, it would already be part of encodeURIComponent.

comment:4 Changed 13 years ago by docwhat

I agree that this should be removed. To see it at work, create a simple page that has a JS action that does a decodeURIComponent() and then re-encodes it with the .replace() and click on it a couple times, the URLs will go from: foo bar,baz foo+bar%2Cbaz foo%2Bbar%2Cbaz

Very annoying.

comment:5 Changed 12 years ago by snover

Resolution: wontfix
Status: newclosed

jQuery conforms to the HTML 4.01 specification, which defines the application/x-www-form-urlencoded content type.

comment:6 Changed 11 years ago by addyosmani

#10119 is a duplicate of this ticket.

comment:7 Changed 11 years ago by anonymous

Ugh... the HTML 4.01 specifications are a pretty strong argument, but it still sucks.

I know tons of people that tweak their jQuery to remove this behavior to save themselves a lot of headaches.

Most things seem to play nicely with spaces as %20... while replacing with + seems to more often cause problems (mostly encountered with other javascript based code that often seems to assume you used encodeURIComponent and thus the process can be reversed with decodeURIComponent... teaches them for assuming!)


mailto:[email protected]

The subject line still has the +


mailto:[email protected]

works (yes, yes, different standards, but I wonder why they made an exception for spaces in forms rather than just sticking to rfc1738).


comment:8 Changed 11 years ago by dmethvin

#11369 is a duplicate of this ticket.

comment:9 in reply to:  1 Changed 11 years ago by anonymous

value = value.replace(/%20/g, " ");

comment:10 Changed 10 years ago by anonymous

While it is correct to conform to http://www.w3.org/TR/html401/interact/forms.html#h- for form data, it is not correct to use that specification for the generic encoding of a URI. The correct document to use is RFC 3986 (http://tools.ietf.org/html/rfc3986) "Uniform Resource Identifier (URI): Generic Syntax". No + encoding of space characters is ever defined, and percent-ecoding the space character is explicitly mentioned:

Section 2.1 (http://tools.ietf.org/html/rfc3986#section-2.1):

A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. A percent-encoded octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing that octet's numeric value. For example, "%20" is the percent-encoding for the binary octet "00100000" (ABNF: %x20), which in US-ASCII corresponds to the space character (SP). Section 2.4 describes when percent-encoding and decoding is applied.

comment:11 Changed 10 years ago by anonymous

Reopen, please, and fix it. This makes is compatible to the native javascript url en/decode functions, which all encode " " as "%20", but do not decode "+" as " ". HTML URL Encoding Reference

comment:12 Changed 10 years ago by anonymous

I'll add my +1 (or is it %2B1?)

The replacing with + appears unnecessary, and a bit annoying for a lot of people.

comment:13 Changed 10 years ago by mikesherov

Thanks for contributing, but please don't post +1's that don't include new information.

+1 doesn't change the reason we closed it. If you have a valid reason for reopening other than it annoys you, we're willing to here it, but the reason we're not fixing is clearly laid out in this report.

comment:14 Changed 9 years ago by [email protected]

There are four reasons to re-open this bug.

  1. The RFC relied upon by JQuery to leave this as unfixed only relates to form encoded content. As mentioned by a previous poster, the appropriate RFC for general URI encoding is http://tools.ietf.org/html/rfc3986#section-2.1
  1. OAUTH authenticated clients must reverse this replacement made by JQuery prior to computing the signature component of the OAUTH header.


  1. When posting data to nodejs based servers, again the JQuery replacment must be specifically accounted for as it is incompatible with native javascript url encoding and decoding functions.
  1. Although multiple practical circumstances show a preference for encoding space as %20 and the appropriate RFC also prefers this encoding, there is no practical benefit to encoding space as '+'.

comment:15 Changed 9 years ago by bendman

This should most definitely be changed, or for backwards compatibility reasons add an option to toggle this functionality. In fact, unless this is changed, the documentation is wrong. There are two functions for a reason.

Param Docs

Description: Create a serialized representation of an array or object, suitable for use in a URL query string or Ajax request.

Serialize Docs

Description: Encode a set of form elements as a string for submission.

Clearly, param should be using standards for URI data (%20), as Michael Walters stated above, while serialize should use standards for form data. Param could take an optional parameter to serialize data using the + character for supporting serialize internally, and for backwards compatibility. Unfortunately if this parameter is exposed as a boolean, it will conflict with the traditional parameter used to support jQuery pre-1.4

Note: See TracTickets for help on using tickets.