net/url: no way to parse absolute URLs

[ThomasHabets]

#1. What version of Go are you using (go version)?

go version go1.7 linux/arm
#2. What operating system and processor architecture are you using (go env)?

GOARCH="arm"
GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/blaha/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build859569037=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

#3. What did you do?

https://play.golang.org/p/W4T12uL3_L

"cache_object" scheme is used by the squid proxy.
#4. What did you expect to see?

RFC3986 section 3.1:

   When presented with a URI that violates one or more scheme-specific
   restrictions, the scheme-specific resolution process should flag the
   reference as an error rather than ignore the unused parts; doing so
   reduces the number of equivalent URIs and helps detect abuses of the
   generic syntax, which might indicate that the URI has been
   constructed to mislead the user (Section 7.6).

I expect to get an error. I.e. for the play.golang.org snippet to panic.
#5. What did you see instead?

"Path" is set to the whole input.

[bradfitz]

I'm not sure there's anything to fix here.

Go interprets the scheme per the spec;

      scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

Which doesn't include "_".

But the part of the spec you cite regarding not ignoring parts on error would apply if we had a function to just parse an absolute URL only. We don't, though: our Parse function is defined (for better or worse) to parse either absolute or relative paths. And if it's not a valid absolute URL, we have no choice but to interpret it as a possible valid relative path.

Maybe we should add a way to parse in absolute mode only, in which case we could return an error.

It still doesn't help you parse "cache_object" bogus schemes.

[ThomasHabets]

Like I said I expect an error, because of the underscore.

Ah. That it would parse relative URLs did not occur to me, but it's even documented.

I'm not sure I'm reading this section 3.3 right:

   In addition, a URI reference
   (Section 4.1) may be a relative-path reference, in which case the
   first path segment cannot contain a colon (":") character

The way I read this "cache_object:" is the first path segment, and thus violates section 3.3. (without throwing an error in the Go implementation). Apologies if I'm misreading.

[rsc]

Looking at the code, (*URL).String gets this right, so we should probably fix Parse. Sent CL 31582.

[gopherbot]

CL https://golang.org/cl/31582 mentions this issue.