I propose adding a PatternContextKey field to net/http, which would be set on a request context by ServeMux. Proposed doc-visible API as follows

var (
	// PatternContextKey is a context key. It can be used in HTTP handlers with Context.Value to access
	// the pattern used by the request router to route a request to a handler. The associated value will be
	// of type string, and can be set by ServeMux or another router where applicable.
	PatternContextKey = &contextKey{"pattern"}
)

When processing a Request, ServeMux should inject the pattern provided to Handle or HandleFunc into a request-context value against this key.

This functionality would extremely helpful for the observability or testability of routing behaviour. It is very helpful to have some sort of key to identify the route an incoming request came via, and currently there is no good way to determine this dynamically from the handler.

It is not always desirable for this key to be the request URL, or part of it. The host may be variable, the handler may be under a prefix, or the URL path may contain high-cardinality variables. To derive a useful key from the URL, dealing with the first two issues requires a handler to know a lot about the routers above it, and the third makes URLs almost unusable. The second issue is that the route may be ambiguous. A request may reach a handler via two different routing paths, perhaps because different middleware was defined on different paths or methods, but the requests are eventually handled by the same code. More likely is that the handler doing the logging or metric-recording is middleware itself, and is called in multiple places with varying requests. These ambiguity and cardinality issues already make this difficult in the existing ServeMux and it is only worse in third-party routers which support path variables. I expect this problem to become more difficult in code using the standard library router if #61410 is accepted.

This can be worked around already, but the methods aren't very satisfactory. A value can be provided statically and either given straight to the handler when instantiating it, or given to a middleware which injects it into the context where it can be pulled out by other code. Both of these require specifying a value for the tag, which either means stuttering the routing pattern or making up a new meaningful tag for every route, both of which feel unpleasantly boilerplate-y and neither of which play well with the ecosystem of handlers and middlewares. Adding a standard way to provide this information would improve how far a user can get with the standard library, and hopefully provide something for the ecosystem to cohere around.

I don't think the net/http package should provide guarantees about the structure of the data in this context value, but I think ServeMux should. This leaves the door open for other routers to add relevant routing info here when they have it, and means they can use this context key without needing to specify their routing patterns in the same format as ServeMux.

The part of this I am undecided on is how nested ServeMuxes should handle this value. In increasing order of both usefulness and complexity:

• Last wins, each router sets it on the context without checking first.
• Simple concatenation, this string is appended to by different router. Leaves the awkward problem of what character to use for the concatenation.
• Smart combination, where a previous value is combined with the new one in order to increase its specificity. This might be impossible to do correctly in all cases for paths as the router doesn't necessarily know if the path has had prefixes stripped already, so can't always combine paths correctly.

I realise not being able to solve this satisfactorily could be a dealbreaker for this, I'm hoping discussion will reveal solutions I haven't seen.

There is prior art for similar functionality in gorilla/mux and chi, both of which support path variables and routing based on methods. I have used these before to provide keys for request-recording metrics, but cannot provide public links.

I previously suggested this in #61410 (comment) as adding a Pattern string field to a Request. I thought better of this as it seemed odd to add a new field to the Request struct specifically to be set server-side by a ServeMux.