What changes when a net/http middleware chain wraps the whole ServeMux instead of individual routes?

## The mux is a handler, which is why there is a choice at all `http.ServeMux` implements `http.Handler` like anything else. Its `ServeHTTP` looks at the method and path, finds the registered pattern that matches, and calls that pattern's handler. Nothing about it is special to `net/http`'s wrapping model, so a chain can sit on either side of it: ``` srv := &http.Server{Handler: Chain(mux, outerWrappers...)} // outside routing mux.Handle("GET /items/{id}", Chain(h, innerWrappers...)) // inside routing ``` The difference is not stylistic. It changes *which requests* a wrapper sees and *what it knows* when it sees them. ## Outside the mux: everything, but blind A wrapper outside the mux runs on every request the server accepts and dispatches, which includes: - requests that match no registered pattern and will be answered with 404 by the mux's not-found handling, - requests whose method does not match any pattern registered for that path, - the mux's own trailing-slash redirect responses, - requests to routes registered after the chain was built, automatically. That completeness is the reason to be out there. A wrapper meant to produce one access-log line per request is worth nothing if the requests that 404 are invisible to it -- those are frequently the interesting ones. The same applies to anything whose value comes from being unconditional. What that position gives up is knowledge. At that point `ServeMux` has not matched anything, so: - `r.PathValue("id")` returns the empty string, because no pattern has been matched to bind wildcards from, - the wrapper knows the raw path (`/items/42`) but not the template it will match (`/items/{id}`), so grouping output by route means guessing from the raw path, - there is no way to say "except for this one route", short of the wrapper re-implementing a path check of its own, which duplicates the routing rules and drifts from them. ## Inside the mux: informed, but partial Registering a chain per route inverts every one of those properties. The wrappers run only after the mux matched, so wildcard values from the pattern are available through `r.PathValue`. Each route chooses exactly the layers it needs, which is the natural way to express a policy that genuinely differs per route. The costs are equally real. Unmatched requests never reach any per-route chain, so nothing registered this way can be relied on for whole-surface coverage. And the wiring is repeated at every registration site, which means the failure mode is omission: someone adds a route in six months, copies the neighbouring line, forgets one wrapper, and nothing complains. A shared registration helper that takes the route pattern and the handler and applies the standard chain is the usual defence -- it makes the wrappers the default rather than something each caller remembers. ## The shape most services end up with A short outer chain for the concerns that must be unconditional and route-agnostic, wrapped around the mux; plus per-route or per-group chains for policies that vary by route, applied through one helper so no registration can quietly skip them. Groups are expressed by building the group's chain once and reusing it across the routes that share it -- Go has no router-level group concept in the standard library, so the composition helper is the grouping mechanism. ## Reviewing it The questions that decide whether a chain is in the right place: does this wrapper need to see requests that match nothing? Then it belongs outside the mux. Does it need to know which pattern matched, or does it apply to only some routes? Then it belongs inside. Does it claim to cover everything but sit at a route? That is the bug -- and it is invisible until somebody asks why the 404s never appear in its output. A test that drives a request to an unregistered path through the assembled server, and asserts that the outer wrappers still emitted their lines, is the cheapest way to keep that property from eroding.