Should url.go modify url beginning with //?

[jmy...@pivotal.io]

http://golang.org/src/pkg/net/url/url.go#692

The url.go package prepends the scheme to RequestUri when the Path begins with "//". In our situation, we are trying to write a transparent proxy that does not modify the path. Since this is in a http server included in the golang core, perhaps it would better be not to add these smarter corrections and instead leave it to those writing more adapted servers out there. Do you think this is reasonable default behavior?

Jim

[Russ Cox]

On Mon, Oct 20, 2014 at 6:24 PM, <jmy...@pivotal.io> wrote:

http://golang.org/src/pkg/net/url/url.go#692

The url.go package prepends the scheme to RequestUri when the Path begins with "//". In our situation, we are trying to write a transparent proxy that does not modify the path. Since this is in a http server included in the golang core, perhaps it would better be not to add these smarter corrections and instead leave it to those writing more adapted servers out there. Do you think this is reasonable default behavior?

At the risk of sounding pedantic, package url is not an http server. There must be more code involved that you're not pointing us at.

For the specific case of package url, you can avoid rewrites if you need to do that by using the Opaque field. See the docs on the URL.String method in the tip.golang.org copy of the sources for details. (The details apply to earlier versions too; we just only added the longer docs recently.)

Russ

[Benjamin Measures]

On Tuesday, 21 October 2014 00:25:02 UTC+1, rsc wrote:

On Mon, Oct 20, 2014 at 6:24 PM, <jmy...@pivotal.io> wrote:

http://golang.org/src/pkg/net/url/url.go#692

At the risk of sounding pedantic, package url is not an http server.

Jim may have a point.

The comment <https://codereview.appspot.com/7369045#msg3> at the foundation of the CL is incorrect:

Given that you can't do an HTTP request with "//foo" (see RFC 2616 5.1.2 Request-URI), it seems best to prepend the scheme to make it an absoluteURI.

RFC 2616 5.1.2 Request-URI <http://tools.ietf.org/html/rfc2616#section-5.1.2>:

       Request-URI    = "*" | absoluteURI | abs_path | authority

RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax <http://tools.ietf.org/html/rfc2396#appendix-A>:

      abs_path      = "/"  path_segments

      path_segments = segment *( "/" segment )
      segment       = *pchar *( ";" param )

RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing <http://tools.ietf.org/html/rfc7230#appendix-B>:

   request-line = method SP request-target SP HTTP-version CRLF
   request-target = origin-form / absolute-form / authority-form /
    asterisk-form

   origin-form = absolute-path [ "?" query ]

   absolute-path = 1*( "/" segment ) 

And finally,

RFC 7230 2.7. Uniform Resource Identifiers <http://tools.ietf.org/html/rfc7230#section-2.7>:

   [...] An

   "absolute-path" rule is defined for protocol elements that can
   contain a non-empty path component.  (This rule differs slightly from
   the path-abempty rule of RFC 3986, which allows for an empty path to
   be used in references, and path-absolute rule, which does not allow
   paths that begin with "//".)