Proposal Details

registering 2 handlers:

mux.HandleFunc("/api/", ApiHandler)
mux.HandleFunc("GET /", VueServer)

results in:

panic: pattern "GET /" (registered at /.../golang/internal/kipurouter/Router.go:38) conflicts with pattern "/api/" (registered at /.../golang/internal/kipurouter/Router.go:38):
GET / matches fewer methods than /api/, but has a more general path pattern

to me, these should not be conflicting routes. this use case is I want all GET routes that aren't matched to load the SPA, and anything that's not GET obviously is a 404 since you're not POSTing to load index.html

I've read the pattern/node/mux code, and I understand why it's conflicting with the current implementation, but I think we could make the experience better

Important Detail:

right now everything panics immediately if there's a conflict, so there would be no production code that would break by a change allowing the router to fallback to ordered routing instead of panicking.

Benefit:

Allow fallback patterns that only matter if other patterns aren't matched first

Alternatively, path should take precedent _first_, _then_ method Just IMO a more specific _path_ pattern should take precedent over a more specific method. any request to `/api/*` should go to `/api/`, not `GET /` just because `/` is a GET request `method` patterns should be for restricting method matches, but should have no affect on path matching precedence. it should be for saying requests _don't_ match unless they match that method, not to say it's more important because it matches the method. method should only be used for specificity in the case of two equivalent matching paths if we were to only match the paths first, it would be obvious that `/api/` goes to `/api/` first and paths without a method should be the implicit equivalent of defining every method individually. not be considered less specific, unless there's an explicitly more specific method match for that pattern

Comment From: seankhliao

I believe this was discussed extensively in #60277 / #61410 . This doesn't appear to be something we'll change.