Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

net/url: document that Parse unescapes paths #3659

Closed
gopherbot opened this issue May 22, 2012 · 10 comments
Closed

net/url: document that Parse unescapes paths #3659

gopherbot opened this issue May 22, 2012 · 10 comments
Labels
FrozenDueToAge
Milestone
Go1.1

Comments

@gopherbot
Copy link
Contributor

by lijie.wong:

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

What is the expected output?
http://a.com/%2f

What do you see instead?
http://a.com//

Which compiler are you using (5g, 6g, 8g, gccgo)?
Which operating system are you using?
Which version are you using?  (run 'go version')
play.golang.org.

Please provide any additional information below.

Under RFC 3986, the two URLs are not equivalent ('/' delimits path segments, whereas
'%2f' is part of a path segment)
@rsc
Copy link
Contributor

rsc commented May 22, 2012

Comment 1:

The RFC and the Go API are at odds here: if r.URL.Path is a single
string, then there is no way to represent %2f as different from /,
since the path is already decoded.  We can't just leave the %2f,
because /%2f is what you get from decoding /%252f.  Short of making
the Path a []string (which would be much less convenient for the vast
majority of code), there's no fix.
Thankfully, very few apps choose to assign special meaning to path
elements containing %2f characters (this pretty much only comes up
during OAuth).  If your app needs to assign special meaning, the
server can reprocess req.RequestURI as it sees fit, and the client can
issue requests using &url.URL{Opaque: rawURI}.
See also issue #2782.
Russ

Status changed to Unfortunate.

@gopherbot
Copy link
Contributor Author

Comment 2 by lijie.wong:

Perhaps it would be better if the broken behaviour were documented? As it is, I have no
clue (besides reading source) that it is. (And since it is broken, I also have no idea
what other deviations from the RFC there are)

@rsc
Copy link
Contributor

rsc commented May 23, 2012

Comment 3:

I will think about what to write.  Thank you for your concern.

Status changed to Thinking.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 5:

Labels changed: added go1.1.

@rsc
Copy link
Contributor

rsc commented Sep 13, 2012

Comment 6:

Labels changed: added priority-later, removed priority-triage.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 7:

Labels changed: added size-s.

@rsc
Copy link
Contributor

rsc commented Jan 31, 2013

Comment 8:

Issue #4732 has been merged into this issue.

@rsc
Copy link
Contributor

rsc commented Jan 31, 2013

Comment 9:

This issue was closed by revision 4085426.

Status changed to Fixed.

@gopherbot
Copy link
Contributor Author

Comment 10 by hongruiqi:

The cleanPath is applied to r.URL.Path.
So /%2f is unescaped to //, and cleanPath turns it to /. Then a redirect is responsed.
If cleanPath applies to r.RequestURI's path part, there is no change to
cleanPath("/%2f"). So no redirect happened. The handler matches "//"(r.URL.Path) is
called.
When the path is "//", it is redirected to "/" and not passed to the handler, the same
as before.

@adg
Copy link
Contributor

adg commented Oct 25, 2013

Comment 11:

Issue #6658 has been merged into this issue.

@rsc rsc mentioned this issue Dec 8, 2014
Closed
@adg adg mentioned this issue Dec 8, 2014
Closed
@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
rsc added a commit that referenced this issue Jun 22, 2015
@rsc
net/url: add RawPath field, a hint at the desired encoding of Path
874a605 
Historically we have declined to try to provide real support for URLs
that contain %2F in the path, but they seem to be popping up more
often, especially in (arguably ill-considered) REST APIs that shoehorn
entire paths into individual path elements.

The obvious thing to do is to introduce a URL.RawPath field that
records the original encoding of Path and then consult it during
URL.String and URL.RequestURI. The problem with the obvious thing
is that it breaks backward compatibility: if someone parses a URL
into u, modifies u.Path, and calls u.String, they expect the result
to use the modified u.Path and not the original raw encoding.

Split the difference by treating u.RawPath as a hint: the observation
is that there are many valid encodings of u.Path. If u.RawPath is one
of them, use it. Otherwise compute the encoding of u.Path as before.

If a client does not use RawPath, the only change will be that String
selects a different valid encoding sometimes (the original passed
to Parse).

This ensures that, for example, HTTP requests use the exact
encoding passed to http.Get (or http.NewRequest, etc).

Also add new URL.EscapedPath method for access to the actual
escaped path. Clients should use EscapedPath instead of
reading RawPath directly.

All the old workarounds remain valid.

Fixes #5777.
Might help #9859.
Fixes #7356.
Fixes #8767.
Fixes #8292.
Fixes #8450.
Fixes #4860.
Fixes #10887.
Fixes #3659.
Fixes #8248.
Fixes #6658.
Reduces need for #2782.

Change-Id: I77b88f14631883a7d74b72d1cf19b0073d4f5473
Reviewed-on: https://go-review.googlesource.com/11302
Reviewed-by: Brad Fitzpatrick <[email protected]>
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.1
Development

No branches or pull requests
3 participants
@rsc @adg @gopherbot