[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus

[Stephen Day]

Stephen Day <stevvooe at gmail.com> added the comment:

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________