Go: net/url: issue with encoding spaces

[gopherbot]

by [email protected]:

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. http://play.golang.org/p/Hal0slZDI9

What is the expected output?

Tue%20Aug%2028%2013%3A52%3A20%20UTC%202012

What do you see instead?

Tue+Aug+28+13%3A52%3A20+UTC+2012

Which version are you using?  (run 'go version')

go version go1.0.2 (appengine-1.7.1)

Please provide any additional information below.

http://golang.org/pkg/net/url/ says "Package url parses URLs and implements query
escaping. See RFC 3986.", and spaces ' ' should be %20 rather than +

[minux]

Comment 1:

QueryEscape escape the query part of the URL,
and a space in query is escaped as +.

_Status changed to WorkingAsIntended._

[Grovespaz]

Comment 2:

Is that actually specified somewhere?
net/url assumes a query parameter to follow application/x-www-form-urlencoded rules
instead of RFC's.
RFC1738 defines + as an allowed character but doesn't specify it to be a space, even
though it is commonly regarded as such.
RFC3986 seems to recommend %20 for spaces.
net/url makes a special case out of the space, even though url.go refers to RFC3986.
If I recall correctly the + sign is used when a browser submits a form to an url, for
legacy reasons(?) when using mime-type 'application/x-www-form-urlencoded'.
This is, however, not part of an RFC?
So both forms are in use and both appear to be syntactically correct (even though using
the + sign is older but more readable), so when encoding one just has to choose.
See also:
http://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www-form-urlencoded_type

[gopherbot]

Comment 3 by psnim2000:

It seems that the query portion can be escaped as "%20" or "+" and the path portion can
only be escaped as "%20".
I was using this function to generate paths and because "+" did not become spaces,
according the browser, there was an unintended consequence.
It seems to me it would be better to have it encode to "%20" as they work for both cases.

[gelraen]

API for proper percent-encoding would be still nice to have.