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

Implement multipart file uploads #75

Open
abonander opened this issue Sep 30, 2019 · 5 comments
Open

Implement multipart file uploads #75

abonander opened this issue Sep 30, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@abonander
Copy link
Contributor

abonander commented Sep 30, 2019

I couldn't find anywhere documenting a desire or otherwise a lack of desire for multipart/form-data support.

I have a very basic streaming multipart client API in multipart-async now: https://github.com/abonander/multipart-async/tree/master/src/client

It's not quite production ready yet though. I want to add several more tests. It's also built against tokio-io instead of futures-io. Whoops.

@yoshuawuyts yoshuawuyts added the enhancement New feature or request label Oct 2, 2019
@yoshuawuyts
Copy link
Member

@abonander yeah, having this would be great! -- I considered implementing it before the initial release, but this is somewhat tricky and we'd need to come up with a good design first. Would you like to work on bringing this into Tide?

@abonander
Copy link
Contributor Author

abonander commented Oct 3, 2019

@yoshuawuyts Tide or Surf? I also have a server API that's just about ready for use which would close http-rs/tide#89. I mostly just want to do a bunch more testing to really be confident in it but it's already better tested than multipart ever was since I have the benefit of hindsight.

I think the client API design is comparatively straightforward, though. The main question is whether it should be lazy (pass a list of fields and the client processes them in a single call at the end) or eager (actively write each field to the transport). We have a much better error handling story in Rust now than when I developed the original multipart client API (which the lazy API was meant to paper over so every call didn't need to be wrapped in try!()) so I think just an eager API might be fine.

@futurist
Copy link

futurist commented Oct 30, 2020

What's the plan of this feature? It's an important feature I think (or maybe bug?)

@Fishrock123
Copy link
Member

See http-rs/http-types#175 - likely to picked back up soon over there, unsure how or when that will impact a full surf api for this.

@Fishrock123
Copy link
Member

I don't have any investment in this anymore. Someone else will need to pick it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants