Stephen Day <stevv...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
