http.Handle("/", ...) effectively hijacks pages from being not found (due to trailing "/" in the "pattern")

[gopherbot]

by montsamu:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. http.Handle("/", SomeFunc);
2. visit your web server "/notfound"

What is the expected output? What do you see instead?

Expected output is a 404 page; instead the SomeFunc result behaviour occurs 
because "/" is treated as any other pattern instead of allowing an exact 
match only.

What is your $GOOS?  $GOARCH?

sam@sol:~/go$ set | grep GO
GOARCH=amd64
GOOS=linux
GOROOT=/home/sam/go

Which revision are you sync'ed to?  (hg log -l 1)

sam@sol:~/go$ hg log -l 1
changeset:   4068:57c2810ca63f
tag:         tip
user:        Robert Griesemer <[email protected]>
date:        Mon Nov 16 08:58:55 2009 -0800
summary:     - Clarify that struct composite literal keys are field names 
not selectors.

Please provide any additional information below.

I am requesting a means of specifying an exact pattern only in a ServeMux, 
specifically to handle the the case of "/" instead of the default pattern 
behavior for patterns ending in a slash. There may be such a behavior but 
it is not documented at: http://golang.org/pkg/http/#tmp_272

(Some examples might be: allow "/$" to mean an exact path match only 
instead of the default sub-pattern handling.)

[gopherbot]

Comment 1 by montsamu:

Alternatively or better, perhaps another interface into the Mux system using lower-
level regex calls (if that is what is underneath the default Mux "pattern language").
Ex: http.HandleRegex("/$", SomeFunc)
Or have it be type specific and just:
http.Handle(SomeRegexObject, SomeFunc)

[griesemer]

Comment 2:

Owner changed to [email protected].

[rsc]

Comment 3:

I have to think more about this.  I like the current
not-pattern-based approach.  Regexps are overkill
for this kind of thing and too easy to get wrong.
A workaround is for the handler to check for just "/":
    if r.URL.Path != "/" {
        http.NotFound(c, r);
        return;
    }

Status changed to Thinking.

[gopherbot]

Comment 4 by montsamu:

Agree on the workaround being simple; and that regexps can be overkill. However now 
you've also introduced another "URL matching language" instead of perhaps using one 
already familiar.
I would suggest:
http.Handle(string, SomeHandler) to be the exact string only (or if you must the "URL 
pattern language" which is currently used, though I do think the common case is for 
exact string) and:
http.HandleRegexp(SomeRegexp, SomeHandler) when something else is required.
(Apologies for silly suggestion of method overloading, I had not fully read the Go 
specification to understand that this is not done in Go at the time of the issue 
being opened.)

[rsc]

Comment 5:

The URL matching language is not new.  It is file+directory names,
which are about as old as regular expressions.
Like I said, I'm thinking about it.

[gopherbot]

Comment 6 by montsamu:

It's file and directory names, with the important addition that directory names (ending 
with "/") become catch-all for any longer paths.
Thanks very much for the consideration.

[rsc]

Comment 7:

Labels changed: added packagechange.

[gopherbot]

Comment 8 by tdhutt:

"directory names (ending with "/") become catch-all for any longer paths."
I thought it was designed to be like that, so you can easily implement something like:
http://traintimes.org.uk/london/cambridge

[rsc]

Comment 9:

I've thought more about this and don't think it warrants the
complexity of adding another function to the interface.
The workaround in comment #8 is straightforward and simple.

Status changed to WorkingAsIntended.