Comment 1:

One answer which you might not like:
The ServeMux isn't fundamental to the net/http package.  If you don't like its behavior,
you can write your own mux.  Several people in the community have.  I often do my own
routing when a ServeMux is over- or under-kill.

Comment 2 by alec@swapoff.org:

What an odd coincidence... I also hit this today. It was quite confusing.
Writing your own mux (or using an existing one like gorilla) is a workaround, but given
the corresponding loss of integration with other stdlib packages like expvar and
net/http/pprof, not a great one.

Comment 3:

Sure, working around this is straightforward.  Even simpler is:
func indexHandler(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path != "/" {
        http.NotFound(w, r)
        return
    }
        ....
}
What concerns me is that serving that page at all endpoints is a bug
that was latent in my program.  I'd like to help others not have that
bug.
I still like the idea of "/" including all paths and "" including the
root only, similar to the trailing slash in "/foo/" vs. "/foo".  The
other suggestions expand the API more than I think is justified.

Comment 4:

I am not sure this is worth fixing. If it is worth fixing, then "" is the
answer. http.ExactPath is overkill: the only thing it would be good for is
this one situation.

Comment 6:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

Comment 7:

My opinion is that "" should be a bug.
"/" is a good pedagogical case. A lot of people don't know that "/foo/" matches
"/foo/.*".
Perhaps the answer is more examples?

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

Status changed to Accepted.

Comment 8:

I don't think it is a good idea to make it easy to serve the same page at all paths,
even though it does seem clean when you understand the mechanism.  Let me give some
examples of how serving the same content for every page is harmful.
1. You have a load balancer that health-checks a number of backends and forwards queries
to the ones that are serving 200s.  By mistake, you include a machine in the pool that
is serving a different service.  Everything appears to work, but you are unknowingly
serving the wrong content to some fraction of users.  The fix is to health-check not /
but /healthy-for-foo; 404s from other backends will stop them from seeing user traffic,
and your monitoring will pick up the unhealthiness of the incorrectly configured
backends.
2.  becomes a valid link, not to http://www.foo.bar/path as
you intended but to http://www.your.site/www.foo.bar/path.  If you crawl your site
checking broken links, this won't be noticed.  No errors will appear in your logs.
3. Trolls can construct valid URLs to your site with "creative" paths.  They can send
links to these paths to other users, and they can get search engines to crawl and index
them.
Therefore I think it should be the best practice to serve 200 for / and 404 for
everything else.
I think "" is the easiest API to use, but if you prefer, we could also document that
everyone using ServeMux should include boilerplate on their / handler to serve only /.

Comment 9:

You make good points. Whether it is a good idea or not is irrelevant now. The behaviour
of Handle("/", too) is set in stone for Go 1.x.  
This issue is about the possibility of changing the meaning of the "" path, and any
documentation changes. I think a good example on Handle could clear up a lot of
confusion.

Comment 10:

Labels changed: added go1.2maybe.

Comment 11:

Labels changed: added documentation.

Comment 12:

This issue was closed by revision 1a819be.

Status changed to Fixed.