This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Stephen.Day
Recipients Stephen.Day, eric.araujo, ezio.melotti, maker, orsenthil
Date 2012-02-23.20:01:01
SpamBayes Score 6.1806166e-10
Marked as misclassified No
Message-id <1330027262.81.0.49889942612.issue13866@psf.upfronthosting.co.za>
In-reply-to
Content
While it's likely that adding a `quote`/`quote_plus` function paramater to urlencode is the right solution, I want to ensure that the key point is communicated clearly: encoding a space as a '+' is pathological, in that in the common case, an unescaped encoded character is indistinguishable from a literal '+'. Take the case of the literal string '+ '. If one uses the javascript encodeURI function to encode the string in a browser console, one gets the following:

> encodeURI('+ ')
"+%20"

Now, we have a string that will not decode symmetrically. In other words, we cannot tell if this string should decode to '  ' or '+ '. And while use of encodeURI is discouraged, application developers still use it places, introducing these kinds of errors.

Conversely, we can see that the behavior of encodeURIComponent, is unambiguous:

encodeURIComponent('+ ')
"%2B%20"

And while these are analogues to quote and quote_plus (there exists now analogue to javascripts urlencode), it's easy to see that disambiguating the encoding of the resulting output of urlencode would be desirable.

There is a similar situation with php library functions. 

Furthermore, it is agreed that urlencode does follow the rules, but the rules, as they are, introduce an asymmetrical, pathological encoding. Most services accept '%20' as space in lieu of '+' when data is encoded as 'application/x-www-form-urlencoded' anyway.

Concluding, I know it seems a little silly to spend time filing this bug and provide relevant cases, but I'd like to cite professional experience in this matter; I have seen "pluses-for-spaces" introduce errors time and time again.
History
Date User Action Args
2012-02-23 20:01:02Stephen.Daysetrecipients: + Stephen.Day, orsenthil, ezio.melotti, eric.araujo, maker
2012-02-23 20:01:02Stephen.Daysetmessageid: <1330027262.81.0.49889942612.issue13866@psf.upfronthosting.co.za>
2012-02-23 20:01:02Stephen.Daylinkissue13866 messages
2012-02-23 20:01:01Stephen.Daycreate