David Pedersen

axum is moving to its own body type (https://github.com/tokio-rs/axum/pull/1584) so we don't actually need this anymore. Things have also changed for hyper 1.0 so I'll close this for now.

imo that's fine. It's what axum does for [extractor rejections](https://docs.rs/axum/latest/axum/extract/index.html#accessing-inner-errors). While not _great_ I think its pragmatic and acceptable.

I think it's worth exploring!

Yeah I agree it should feel very close to the existing API. I also think how axum doesn't allow overlapping routes is an important feature and any additional routing we...

I haven't read the code very closely but my impression is that it introduces a lot of new complexity that I don't think is worth while. I'd be more interested...

I'm still not convinced that making the routing more complicated is worth it for this use case. Using an extractor to handle different `content-type`s still feels like the right approach...

I think we should keep this issue open as this is a use case that makes sense for axum to support. The hard part is figuring out how to best...

@Kinrany something like that has been suggested before but I'm not sure it would provide much value and probably make things harder to use. I think needing routing is pretty...

I've been thinking that you can use [`Handler::or`](https://docs.rs/axum-extra/latest/axum_extra/handler/trait.HandlerCallWithExtractors.html#method.or) from axum-extra to get something pretty similar to the top comment: ```rust let app = Router::new().route( "/", get(with_content_type::(json) .or(with_content_type::(text)) .or(fallback)), ); async...

I don't believe you can add middleware to handlers in an "or" because reasons :P you need to know which extractors something needs to know if one of them reject...