-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add axum_extra::extract::Multipart
#1692
Conversation
Are we certain the things people tried to do and ran into compile errors with ultimately worked? I got the impression that most or all of them would have led to runtime panics instead if converted to this API. |
This is mainly for fixing things like #1644 where you wanna stream the contents of the fields somewhere else, perhaps to upload the data somewhere. The use cases we've heard about where people wanna find a field by name and do things with it would most likely result in runtime errors. But thats probably the wrong way to approach the problem in the first place. |
I had (and actually still have) a case where I wanted to stream a field of a multipart upload directly to S3 and got a similar problem as the user in the discussion linked by David. |
@jplatte should we merge this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't reviewed in detail, but sure.
It is is similar to
axum::extract::Multipart
except that it enforces field exclusivity at runtime instead of compile time.I kinda wish we didn't have to do it honestly. Tracking lifetimes at compile feels much more correct but we've learned that it causes lots of headaches, especially because
Field
not being'static
.I'm thinking for 0.7 we can move this into axum but keep it in axum-extra in the meantime.