I see your point about backwards compatibility, but I don't think it'll be
an issue because of two things:

1) If they are using a custom handler for their error handling, that
behavior doesn't change at all.  The only difference is that temporarily
the error information will get added to the context, but it won't be used
and should be cleared.

2) The implementation of the original HTTP Not Found Handler always returns
a 404.  This, to me, seems undesirable in almost all circumstances.
 Actually, since the HTTP specification necessitates these error codes in
the cases I've provided, I would consider this a bug.

Unless there is a case I'm missing, I think that backwards compatibility
shouldn't be a huge issue for this.  Of course, I'd love to hear your
feedback.


On Mon, Jul 8, 2013 at 6:45 PM, Kamil Kisiel <notifications@github.com>wrote:

> In mux.go:
>
> > +
> > +// Pretty-Prints map[string][]string to a pretty formatted string
> > +func mapListToString(m map[string][]string) string {
> > +    output := []string{}
> > +    for key, val := range m {
> > +        entry := key
> > +        if val != nil {
> > +            entry += "=" + strings.Join(val, "|")
> > +        }
> > +        output = append(output, entry)
> > +    }
> > +    return strings.Join(output, ", ")
> > +}
> > +
> > +// Default handler for when a URL was not matched
> > +func NotFound(w http.ResponseWriter, r *http.Request) {
>
> Kind of. Basically by default it would be good if it worked exactly like
> it does now, in case people are relying on the existing behaviour.
>
> However we could provide a NotFoundHandler struct type that could have
> some boolean options to enable different features. Someone who wanted mux
> to be more clever about error handling could then install that as their not
> found handler.
>
> For example
>
> type NotFoundHandler struct {
>     // Return StatusMethodNotAllowed and set the Allow header for requests with invalid methods
>     AllowedMethods bool
> }
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/gorilla/mux/pull/26/files#r5078472>
> .
>