Skip to content
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 a native way to create and respond to requests with multipart forms #2624

Closed
1 task done
zleyyij opened this issue Feb 28, 2024 · 2 comments · Fixed by #2654
Closed
1 task done

Add a native way to create and respond to requests with multipart forms #2624

zleyyij opened this issue Feb 28, 2024 · 2 comments · Fixed by #2654
Labels
A-axum-extra C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Experience needed to fix: Medium / intermediate

Comments

@zleyyij
Copy link
Contributor

zleyyij commented Feb 28, 2024

  • I have looked for existing issues (including closed) about this

Feature Request

Motivation

Currently, as far as I can tell, Axum does not provide a native way to respond to requests with multipart forms.

An endpoint might return a multipart form for a variety of reasons, but the most common being the need to include multiple pieces of data (a json, a file, plaintext) in a single request.

For example, I would like to send a json and a file in a single response.

Proposal

I am not comfortable with the Axum codebase, so I am unsure of the most idiomatic ways do this, but there are a few options that may work:

Implement IntoResponse for the Multipart extractor, and add methods like add_field() to the existing impls for multipart.

It may also make more sense to create a separate MultipartBuilder and implement IntoResponse for that type, and add builder methods, Reqwest's implementation could be used as a reference.

I don't think there are any significant drawbacks, it will marginally increase the complexity of exposed formdata APIs, but I believe the benefits outweigh the drawbacks.

Alternatives

As far as I can tell, alternatives involve:

  • Having users wrap reqwest's implementation and manually interop
    • This adds a level of complexity, for no real advantages from an interface perspective.
  • Having users entirely create multipart form builders from scratch.

I am willing to attempt to implement this, however I am not confident in my abilities to do so.

@jplatte jplatte added C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Experience needed to fix: Medium / intermediate A-axum-extra labels Feb 29, 2024
@jplatte
Copy link
Member

jplatte commented Feb 29, 2024

Implementing IntoResponse for the Multipart extractor seems extremely hard to impossible. I think a separate type would make more sense. Further, I think such a thing is niche enough that it shouldn't go into the axum crate, but axum-extra could fit.

@zleyyij
Copy link
Contributor Author

zleyyij commented Feb 29, 2024

I'll look into adding a separate type to to axum-extra, although I don't know how far I'll get.

Thanks for the feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-axum-extra C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Experience needed to fix: Medium / intermediate
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants