axum 如何为路径存在但不支持的方法设置 405 fallback【免费下载链接】axumHTTP routing and request-handling library for Rust that focuses on ergonomics and modularity项目地址: https://gitcode.com/GitHub_Trending/ax/axum在 axum 中处理请求时你经常会遇到这样一种情况请求的路径是存在的比如/注册了GET处理函数但请求方法是该路径不支持的比如用POST访问。此时你希望用一个专门的 handler 来响应这类请求而不是让框架默认的 405 直接返回。axum 从 0.7.8 版本开始提供了Router::method_not_allowed_fallback方法来解决这个问题它为「路径已注册、但请求方法没有对应 handler」的所有路由统一挂一个 fallback handleraxum/CHANGELOG.md 中记录了该 API 的加入。这篇文章的目标是在一个 axum Router 上正确配置方法级 fallback并验证它在三种请求下方法匹配、路径匹配但方法不支持、路径完全不存在分别由哪个 handler 响应。先分清 axum 的三种 fallback写配置之前先要区分文档中的三个容易混淆的 API它们的触发条件各不相同Router::fallback仅当没有任何路由匹配该请求的路径时调用。请求命中了有效路径但方法不支持时它不会被调用详见 routing/fallback.md。MethodRouter::fallback挂在单个路径上当该路径的MethodRouter没有对应方法的 handler 时调用是 per-route 的方法 fallback详见 method_routing/fallback.md。Router::method_not_allowed_fallback挂在 Router 上为所有已注册的MethodRouter统一设置方法 fallback当某个路径命中但没有匹配请求方法的 handler 时调用详见 method_not_allowed_fallback.md。如果只是想给某一个路径定制方法级响应用MethodRouter::fallback即可如果希望整个应用统一处理「方法不支持」用Router::method_not_allowed_fallback。下面以统一处理为主路径。配置 method_not_allowed_fallback以下是 method_not_allowed_fallback.md 中的完整示例。它注册了三个 handlerhello_world处理GET /default_fallback处理路径完全不匹配的情况handle_405处理路径存在但方法不支持的情况use axum::{response::IntoResponse, routing::get, Router}; async fn hello_world() - impl IntoResponse { Hello, world!\n } async fn default_fallback() - impl IntoResponse { Default fallback\n } async fn handle_405() - impl IntoResponse { Method not allowed fallback } #[tokio::main] async fn main() { let router Router::new() .route(/, get(hello_world)) .fallback(default_fallback) .method_not_allowed_fallback(handle_405); let listener tokio::net::TcpListener::bind(0.0.0.0:3000).await.unwrap(); axum::serve(listener, router).await; }需要注意两点.method_not_allowed_fallback(handle_405)作用于调用它之前已经通过.route(...)注册的所有MethodRouter。这个 handler 是一个普通 handler同样支持提取器和状态。仓库测试 fallback.rs 中展示了它配合with_state使用的写法let app Router::new() .route(/, get(|| async { index })) .method_not_allowed_fallback(|State(state): Statestatic str| async move { state }) .with_state(state);验证三种请求各自落到哪个 handler启动服务后按文档说明用三个请求验证分发行为对http://localhost:3000/发起GET/路径注册了get(hello_world)方法匹配返回hello_world的响应体Hello, world!。对同一地址发起POST路径/存在但该MethodRouter只注册了GET触发handle_405返回Method not allowed fallback。访问一个完全不同的路径如http://localhost:3000/hello没有任何路由匹配触发default_fallback返回Default fallback。也就是说method_not_allowed_fallback只覆盖「路径命中、方法不匹配」这一种情况不会抢占路径不匹配的请求后者仍走Router::fallback。另外两点行为可以从仓库源码和文档中得到确认响应状态码由你的 handler 决定不会被强制改成 405。测试mna_fallback_not_405fallback.rs中 fallback 返回(StatusCode::NOT_FOUND, Not Found)最终响应就是 404且响应中没有Allow头。当 fallback 返回 405 时Allow头会自动补上。顶层路由在响应状态为405 Method Not Allowed时会设置Allow头见 route.rs如果 fallback 的响应里已经自己设置了Allow头则以 fallback 自己的为准见 method_routing/fallback.md。因此如果你用 fallback 扩展额外方法需要自行正确设置Allow头。可选只在单个路径上定制方法级 fallback如果不同路径需要不同的方法级响应而不是全应用统一可以在构造路由时直接用MethodRouter::fallbackuse axum::{ Router, routing::get, handler::Handler, response::IntoResponse, http::{StatusCode, Method, Uri}, }; let handler get(|| async { /* ... */ }).fallback(fallback); let app Router::new().route(/, handler); async fn fallback(method: Method, uri: Uri) - (StatusCode, String) { (StatusCode::NOT_FOUND, format!({method} not allowed for {uri})) }来自 method_routing/fallback.mdfallback的签名带上了Method和Uri方便你在单个路径内按方法和路径做区分。测试mna_fallback_with_existing_fallbackfallback.rs也验证了两者共存时的优先级路径上已有的MethodRouter::fallback优先生效Router 级的method_not_allowed_fallback只处理没有单独挂 fallback 的路径。一个明确的限制两个都设置了 fallback 的MethodRouter不能 mergemerge 时会 panicmethod_routing/fallback.md 中给出了should_panic示例。如果遇到这种冲突可以先用Router::reset_fallback丢掉其中一侧的 fallback 再合并见 routing/mod.rs。适用版本小结method_not_allowed_fallback是 0.7.8 加入的 API0.7 之前的版本没有这个方法只能依赖MethodRouter::fallback逐个路径配置或接受默认的 405 行为axum/CHANGELOG.md。如果你的项目还在旧版本先确认Router上是否有这个方法再决定升级还是按单路径方式配置。【免费下载链接】axumHTTP routing and request-handling library for Rust that focuses on ergonomics and modularity项目地址: https://gitcode.com/GitHub_Trending/ax/axum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考