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

Fancy multipart forms API #14

Open
sagebind opened this issue Oct 28, 2018 · 2 comments · May be fixed by #375
Open

Fancy multipart forms API #14

sagebind opened this issue Oct 28, 2018 · 2 comments · May be fixed by #375
Labels

Comments

@sagebind
Copy link
Owner

sagebind commented Oct 28, 2018

Add an easy-to-use API for creating a multipart/form-data request body and sending it. This API should allow for referencing one or more file streams as form parts. Allowing for files is tricky as described in #7.

There are a couple existing crates we could make use of:

At first glance, none of these appear to support a fully async writing of forms though, except multipart-async which looks unstable, which is unfortunate.

@sagebind sagebind added the enhancement Make a feature better label Oct 28, 2018
@sagebind sagebind added the feature A new feature! label Jul 6, 2019
@sagebind sagebind removed the enhancement Make a feature better label Aug 11, 2019
@ayrat555
Copy link

ayrat555 commented Aug 7, 2021

will this issue be ever resolved? 😄

I wanted to use isahc for my telegram client. but this issue was a blocker :[
https://github.com/ayrat555/frankenstein/blob/master/examples/api_trait_implementation.rs#L113

@sagebind
Copy link
Owner Author

sagebind commented Aug 9, 2021

Technically you don't need this in order to send multipart forms since a multipart form is just bytes. You can craft the request body yourself or use one of the various multipart form libraries on Crates.io to generate such a request body.

One of the primary use-cases for multipart forms is to upload files, but since Isahc's core logic is async, using blocking file I/O is a non-starter. The help wanted label is totally accurate here, since this is a big feature that will require a lot of design and implementation time to do correctly. I'd like to add this at some point though.

@sagebind sagebind linked a pull request Feb 15, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants