The second point seems like another case of a failing extractor and I don't understand the third one.

I believe we currently just send either a 400 or 500 with information about which extractor failed, what would you like axum to send by default? Or am I mistaken and we actually send more information?

There's WithRejection you can use to change the behavior of the rejections though I understand that can get a bit verbose if you plan to do that for every extractor.

I dug through axum's source to put together the complete list.

Extractor rejections

Every built-in extractor exposes detail in its default rejection body before your handler runs. Rejection types that wrap an inner error append it after : , so field names, type names, and parse positions all end up in the response body.

The Extension<T> case is the sneakier one: a missing extension fires a 500 that exposes your middleware structure to the client. If you're relying on extensions set by middleware, a missing one silently tells the caller exactly what your stack looks like.

To remap any extractor's rejection to your own error type, use WithRejection from axum-extra:

use axum_extra::extract::WithRejection;

async fn handler(
    WithRejection(Json(payload), _): WithRejection<Json<MyPayload>, MyError>,
) -> impl IntoResponse {
    // ...
}

Method not allowed (405)

A 405 response includes an Allow header listing every valid method for that path. The cleanest way to handle this globally is Router::method_not_allowed_fallback():

let app = Router::new()
    .route("/users", get(get_users).post(create_user))
    .method_not_allowed_fallback(|| async {
        (StatusCode::METHOD_NOT_ALLOWED, Json(json!({
            "error": "method_not_allowed"
        })))
    });

Axum only injects the Allow header when the response status is 405, and only if the response doesn't already contain one. If your fallback sets its own Allow header, that wins. To suppress routing information entirely, either return a non-405 status or set Allow yourself.

Not found (404)

The default 404 handler returns an empty body. To return structured errors, use Router::fallback():

let app = Router::new()
    .route("/users", get(get_users))
    .fallback(|| async {
        (StatusCode::NOT_FOUND, Json(json!({"error": "not_found"})))
    });

Body too large (413)

The default body limit is 2 MB. When exceeded, axum returns a 413 with body:

Failed to buffer the request body: {inner error}

Configure the limit per-route with DefaultBodyLimit::max(n) or disable it with DefaultBodyLimit::disable():

use axum::extract::DefaultBodyLimit;

let app = Router::new()
    .route("/upload", post(upload))
    .layer(DefaultBodyLimit::max(50 * 1024 * 1024));

Panics

Without CatchPanicLayer, a panicking handler drops the TCP connection. The client gets an incomplete response or a connection reset with no HTTP status code at all. Add CatchPanicLayer from tower-http to return a 500:

use tower_http::catch_panic::CatchPanicLayer;

let app = Router::new()
    .route("/", get(handler))
    .layer(CatchPanicLayer::new());

The default response is a 500 with an empty body.

Middleware short-circuits

Any Tower middleware layer can return a response before your handler runs. The most common ones:

• Authentication middleware returning 401 or 403
• Rate limiting (tower_governor, tower::limit) returning 429
• Timeout (tower::timeout::TimeoutLayer) returning 408 with an empty body

These bypass your error handling layer entirely unless your middleware explicitly routes through it.

What to fix first

1. Add a global fallback for 404 so clients get structured errors instead of empty responses.
2. Add CatchPanicLayer so panics return 500 instead of dropping connections.
3. Audit every Extension<T> extraction — a missing extension is a 500 in production.
4. Use WithRejection for any public-facing extractor where you want structured error bodies.
5. Use method_not_allowed_fallback() if the default Allow header exposure is a concern.