homepage

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.