Implement IntoResponse for MultipartError - #1861
Conversation
So you can return `MultipartError` from handlers without having to downcast the errors yourself. Fixes #1851
|
Great! What a nice work. Your implementation looks fine to me. Let's note that this kind of handling may not work(or make no sense) in future, because of changes of actual error structures. But I think it's not big deal. |
That's always the case and why multer is a private dependency of axum. Then we can change things without breakage. |
| multer::Error::UnknownField { .. } | ||
| | multer::Error::IncompleteFieldData { .. } | ||
| | multer::Error::IncompleteHeaders | ||
| | multer::Error::ReadHeaderFailed(..) |
There was a problem hiding this comment.
I'm not sure if this multer::Error::ReadHeaderFailed is always thrown by the client side. How do you think? Is it OK to response as 400?
There was a problem hiding this comment.
Feels like if the headers cannot be parsed then that's a client issue. The inner error is httparse::Error
| | multer::Error::DecodeHeaderValue { .. } | ||
| | multer::Error::NoMultipart | ||
| | multer::Error::IncompleteStream => StatusCode::BAD_REQUEST, | ||
| multer::Error::FieldSizeExceeded { .. } | multer::Error::StreamSizeExceeded { .. } => { |
There was a problem hiding this comment.
This kind of error will never thrown, because axum does not support constraints of multer.
There was a problem hiding this comment.
But we still need an exhaustive match.
3 participants
So you can return
MultipartErrorfrom handlers without having todowncast the errors yourself.
@AcrylicShrimp what do you think about this?
Fixes #1851