I think allowing extractors to reject and request and forward to the next route is a good idea. Its very similar to rocket's request guards. I haven't tested it yet but I think that should be possible to implement.

However I don't it is possible for .or(ServeDir) to be able to "reject" a request if it doesn't find a matching file. The reason has to do with how or is implemented:

• Fundamentally or has to try and call one service and if that service couldn't handle the request, it needs to call another service with that same request.
• Since tower::Service requires ownership over the request, calling a service means giving up the request. So or cannot "just" call another service with the same request, because the request has been moved.
• The trick that makes it work is that if an axum router couldn't handle a request an EmptyRouter service will always be called. This type is always at the bottom of your router stacks. It will insert the request into a response extension (done here).
• This means when or gets the response back from the first service it is able to know that the request couldn't be handled, as supposed to a handler returning 404, and recover the request. This happens here.
• However the type used by EmptyRouter to pass the request back is private (FromEmptyRouter) meaning other services defined outside axum cannot use it.
• There ServeDir has no way of telling or that it couldn't handle the request and thus .or(ServeDir) will always match all requests.

I haven't thought deeply about if there is a way around it.

Sounds to me like 404 handlers need to be special-cased afterall, then there is no expectation that they will receive the original request 😉

Maybe my 404 handler will just have to be defined like the one in the previous 404 example (MapResponse catching method not allowed / not found and setting the custom body) once I can use .or(ServeDir) instead of .nest(ServeDir) (which I can do once extractors can reject with "please try next route").

A related problem: When extractors are allowed to forward a request on failure, the next handler might fail because it tries to take the request body when that was already taken from the first handler. I'd assume extractors are applied in-order, so should the docs encourage putting body extractors last?

When extractors are allowed to forward a request on failure, the next handler might fail because it tries to take the request body when that was already taken from the first handler. I'd assume extractors are applied in-order, so should the docs encourage putting body extractors last?

Yep that would certainly be an issue. I know warp has the same issue where filters can reject requests in this way. Warp returns a 500 if you attempt to consume the request body twice. So yeah we'd have to document that.

I think allowing extractors to reject and request and forward to the next route is a good idea. Its very similar to rocket's request guards. I haven't tested it yet but I think that should be possible to implement.

I just thought of something. If extractors failing will automatically fallback and try the next route it would cause issues with

Router::new()
    // route that accepts all requests
    .nest("/", _)
    // `Auth ` is an extractor that authorizes requests
    .route("/", get(|_: Auth| async { });

This would cause unauthorized requests to fallback to the nested route, which probably isn't what you'd want.

Assuming we have wildcard routes like .route("/*", _) we'd have the same issue.

Yeah, that's why I only proposed the path extractor changing its behavior. I don't think falling back on something like an invalid JSON payload, missing auth header or non-UTF8 query parameters makes any sense.

Yeah thats true. I wonder if there is a way for extractors to explicitly opt-in to fallback/forwarding. Maybe by returning a special error type 🤔

Yeah, that's roughly what I was thinking. Should probably expose it too so user-defined extractors can opt into the same behavior.

With #408 we now have Router::fallback and Router::or has been renamed to merge and will now literally merge the two routers. No more complex rerouting based on which leaf receive received the request 🥳

While that doesn't allow for extractors to cause fallback I believe this is enough to close this issue.

I do think fallback extractors is an interesting idea but we also have to consider if it could lead to overly complex routers. Also not quite sure how it would work with the new matchit router. Realistically not something axum will support soon but feel free to open a new issue specifically about that to discuss it.