This is the first I've heard of anybody caring about this. That's a pretty delicate API.

As background, we just basically kinda have no place to put this info:
http://play.golang.org/p/4RZwHtWKuV

    u, err := url.Parse("http://example.com/foo")
    fmt.Printf("%#v, %v\n", u, err)

    u, err = url.Parse("http://example.com/foo?")
    fmt.Printf("%#v, %v\n", u, err)

    u, err = url.Parse("http://example.com/foo?a=b")
    fmt.Printf("%#v, %v\n", u, err)

Currently says:

&url.URL{Scheme:"http", Opaque:"", User:(*url.Userinfo)(nil), Host:"example.com", Path:"/foo", RawPath:"", RawQuery:"", Fragment:""}, <nil>
&url.URL{Scheme:"http", Opaque:"", User:(*url.Userinfo)(nil), Host:"example.com", Path:"/foo", RawPath:"", RawQuery:"", Fragment:""}, <nil>
&url.URL{Scheme:"http", Opaque:"", User:(*url.Userinfo)(nil), Host:"example.com", Path:"/foo", RawPath:"", RawQuery:"a=b", Fragment:""}, <nil>

I suppose we could special-case this with RawPath or Opaque, but I'd kinda rather not.

/cc @rsc for opinions.

@bradfitz

That's a pretty delicate API.

I sympathise with your opinion.

I'd kinda rather not.

And, I would understand the rationale.

Via those issue reports, I'm trying to learn what's vendors' take on distinguishing such URLs, as I'm struggling to draw any strict rule from the RFCs.

(Apology for lacking Go fu, I've just kickstarted myself to Go in this mloskot/http-url-test exercise.)

I received some pointers to further details in RFC 3986 (see Is question mark in URL part of query string?). In particular, 6.2.3. Scheme-Based Normalization which somewhat applies to this issue and the "question mark" handling. Quoting:

Normalization should not remove delimiters when their associated component is empty unless licensed to do so by the scheme specification. For example, the URI http://example.com/? cannot be assumed to be equivalent to any of the examples above.

Where "examples above" refers to:

http://example.com
http://example.com/
http://example.com:/
http://example.com:80/

FYI, here is an example of API similar to the one in my issue above:

https://confluence.ucop.edu/display/Curation/ARK

a brief metadata record if you append a single question mark to the ARK
(...)
Adding '??' to the end should return a policy statement.

As people seem to agree, distinguishing these two is very likely a mistake. You say it is an internal API. I don't believe there are any examples of external APIs that demonstrate this problem, so we're not likely to make changes for a single non-public (and therefore not widely used) server.

What about http://server.com/api/item.json?aegjadrlfgdks= or http://server/api/item.json?1 ? Does the server ignore unexpected variables, or is that yet another page?

It is still possible to create an HTTP request explicitly and then modify its URL to set the Opaque field to "/api/item.json?", if you must make calls to the server this way.

I don't think we should take any steps to help the situation unless there is evidence that it's a common problem for Go users. It seems like an isolated incident.

@rsc I understand your rationale and I don't aim to keep requesting any changes.

However, just to address some of your points

• I found a public API which uses similar scheme (see my comment above about https://confluence.ucop.edu/display/Curation/ARK).
• the current implementation of net/http does not completely conform to the RFC 3986 on normalization (again, see my previous comment).

Amusingly, I just discovered that my Hunter Douglas Powerview blinds at home have this problem.

The blinds have a manual remote control that speaks some radio protocol, but there's also the "Powerview Hub" which puts the blinds on your wifi with an app. The Hub runs an HTTP server on port 80 speaking unauthenticated, unencrypted JSON.

But .... if you leave off the trailing question mark in certain queries, the hub crashes.

Another person who hit this: http://forum.universal-devices.com/topic/16538-hunter-douglas-powerview-control-with-isy/ who says:

3 - Whew, now time to get the SceneID's, open a browser, I used Chrome, enter http://(Your Hub IP)/api/scenes? (note: the ? is required or the hub will hang) If all goes well, you should get a JSON result like this: (Mine of course, yours will vary)

I'm reopening this bug, not because we'll necessarily change anything, but because it was closed for lack for external examples.

I suppose we could, for Go 1.7, add a new field ForceQuery bool to url.URL, set it to true during url.Parse (only) when the URL ends in ? with no actual query string, and then change the printer to say if u.ForceQuery || u.RawQuery != "" instead of where it presumably today says if u.RawQuery != "".

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

It looks like this improperly parses URLs if the query string ends in ?, such as http://host/?q=?.

@bjkail, please file a new bug and reference this one.