Skip to main content

Bug Tracker

Side navigation

#3400 closed enhancement (wontfix)

Opened September 23, 2008 02:44PM UTC

Closed November 17, 2010 05:21AM UTC

Last modified January 30, 2014 12:26PM UTC

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:
Description

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?

Attachments (0)
Change History (15)

Changed September 23, 2008 10:52PM UTC by flesler comment:1

owner: → joern

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

Changed September 24, 2008 07:49AM UTC by joern comment:2

owner: joernjohn

John changed that as part of [3115].

Changed July 02, 2009 05:06AM UTC by ecmanaut comment:3

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

Changed December 04, 2009 10:40PM UTC by docwhat comment:4

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.

Changed November 17, 2010 05:21AM UTC by snover comment:5

resolution: → wontfix
status: newclosed

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

Changed August 23, 2011 02:16PM UTC by addyosmani comment:6

#10119 is a duplicate of this ticket.

Changed October 12, 2011 11:33PM UTC by anonymous comment:7

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!)

Interestingly,

mailto:bloke@somewhere?subject=Hello+World

The subject line still has the +

whereas:-

mailto:bloke@somewhere?subject=Hello%20World

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

rfc1738

Changed February 21, 2012 08:59PM UTC by dmethvin comment:8

#11369 is a duplicate of this ticket.

Changed June 01, 2012 05:08AM UTC by anonymous comment:9

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

Changed November 26, 2012 05:59AM UTC by anonymous comment:10

While it is correct to conform to http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 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.

Changed November 30, 2012 02:57PM UTC by anonymous comment:11

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

Changed January 18, 2013 01:49PM UTC by anonymous comment:12

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

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

Changed January 18, 2013 04:24PM UTC by mikesherov comment:13

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.

Changed January 21, 2014 06:24AM UTC by michael.walters@shortcuts.com.au comment:14

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

2. OAUTH authenticated clients must reverse this replacement made by JQuery prior to computing the signature component of the OAUTH header.

http://tools.ietf.org/html/rfc5849#section-3.6

3. 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.

4. 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 '+'.

Changed January 30, 2014 12:26PM UTC by bendman comment:15

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