Discovered while working on something else that we didn't properly
handle this:
```rust
let one = Router::new().route("/", get(|| async {}));
let two = Router::new().route("/", post(|| async {}));
let app = one.merge(two);
```
This introduces two new possible panics when constructing routers:
- If merging two routers that each have a fallback. Previously that left
side fallback would be silently discarded.
- If nesting a router that has a fallback. Previously it would be
silently discarded.
Overall this should make things more explicit and users shouldn't have
to worry "why isn't my fallback" working.
Fixes#488
* Add `axum-extra` crate
Empty for now but now we have a place to put stuff.
I'll make a PR for moving over https://github.com/davidpdrsn/axum-resource.
* remove `authors` field from `Cargo.toml`s
* Move `axum-handle-error-extract` into axum
With 0.4 underway we can now nuke `axum-handle-error-extract` and move
its code directly into axum.
So this replaces the old `HandleErrorLayer` with one that supports async
functions and extractors.
* changelog
* fix CI
* Empty crate
* basic setup
* Support `HEAD`
* Add remaining methods
* Impl Debug
* Add `MethodRouter::merge`
* WIP
* Support same route with different methods in different calls
* Update changelog
* Bring back `any` and `any_service`
* Address review feedback
* Clean up axum-debug crate
Mostly just brings the crate more in line with the rest of the crates in
the workspace.
I've also removed the axum-debug-macros crate since axum-debug only
contained one re-export from axum-debug-macros. So we didn't need two
crates. Can always bring the "backend" crate back if we need things in
axum-debug that aren't proc-macros.
* Just testing: This should make CI fail
* Misc CI clean up
* fix intentional breakage
* fix changelog
* Remove rustfmt config for now as it gives warnings on stable
* Fix paths
* add axum-debug to workspace
* update readme
* add changes to changelog
* little docs update
* fix the gap
a tab has leaked into workspace Cargo.toml, it must be fixed
* address clippy warnings
* Implement `IntoResponse` for `http::response::Parts`
Not sure there are many use cases for this but still thinks it makes to
provide since other crates can't.
* Use `Response::from_parts`
- **added:** Add `Router::route_layer` for applying middleware that
will only run on requests that match a route. This is useful for middleware
that return early, such as authorization ([#474])
[#474]: https://github.com/tokio-rs/axum/pull/474
This addresses something thats been bothering me for some time: Most middleware need to run regardless if the request matches a route or not. For example you don't wanna skip logging for unmatched requests.
However middleware such as authorization only make sense to run for matching requests. This previously wasn't possible to express and you'd have to manually apply the middleware to each handler. Consider this:
```rust
Router::new()
.route("/foo", get(|| async {}))
.layer(RequireAuthorizationLayer::bearer("password"));
```
Calling `GET /foo` with an invalid token would receive `401 Unauthorized` as expected however calling some unknown route like `GET /not-found` would also return `401 Unauthorized`. I think this is unexpected and have seen a few users ask questions about it.
It happened because the 404 you'd otherwise see is generated by a fallback service stored on `Router`. When adding a layer to the router the layer would also be applied to the fallback, which in the case of auth means the fallback would never be called for unauthorized requests.
I think what axum does today is the right default however I still think we should support this somehow. Especially since [`extractor_middleware`](https://docs.rs/axum/0.3.1/axum/extract/fn.extractor_middleware.html) is mainly useful for auth but it doesn't work great today due to this gotcha.
This PR proposes adding `Router::layer_on_matching_route` which only applies layers to routes, not the fallback, which fixes the issue. I'm not a big fan of the name `layer_on_matching_route`, would like something shorter, but I think it communicates the purpose decently.
The generics are a bit different since the request body used on the routes and the fallback must match, so layers that changes the request body type are not compatible with `layer_on_matching_route`. Such middleware are very rare so that should be fine.
