proposal: net/http: Match "Conflicting" Routes in the order theyre defined instead of panicking #74743
Description
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