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

HTTPClientRequest - multipart/form-data Support #32

Open
vnayar opened this issue Mar 13, 2024 · 2 comments
Open

HTTPClientRequest - multipart/form-data Support #32

vnayar opened this issue Mar 13, 2024 · 2 comments

Comments

@vnayar
Copy link
Contributor

vnayar commented Mar 13, 2024

Is it currently possible to use HTTPClientRequest to send requests with content-type multipart/form-data? An example use-case would be to send a request to an endpoint that takes a file as an upload.

The protocol is described here in RFC 2388: https://datatracker.ietf.org/doc/html/rfc2388

An example endpoint that uses this protocol would be GitLab's POST /api/v4/projects/{id}/uploads endpoint: https://docs.gitlab.com/ee/api/projects.html#upload-a-file

Is this an area where contributions are desired? And if so, what is the intended interface for using this capability? I suspect the HTTPClientRequest::writePart() function is meant to be involved, but I'm not super clear what a simple invocation would look like.

@s-ludwig
Copy link
Member

There is currently no high-level implementation for this, so the request body would have to be composed manually. I initially thought there was an implementation, but that was just some e-mail composition code ("multipart/mixed", "multipart/alternative", "multipart/related") that we are using internally. The API of that isn't really suitable for use with the HTTP client, though, so it doesn't make much sense to take that.

As for writePart, it has been too long since it has been added like that and I honestly didn't even know it existed. However, as is, it doesn't look like a useful approach - I'd remove it together with the MultiPart struct. As a baseline, I'd probably go for something that writes everything at once, such as writeMultiPartForm(FormFields form_fields, FilePartFormFields files) (consistent with vibe.inet.webform.parseMultPartForm), or writeMultiPartForm(DictionaryList!MutiPartFormField fields), where MultiPartFormField is a TaggedUnion of union { string text; FilePart file; }.

vibe.inet.webform.FilePart may need a little overhaul for that (the tempPath member doesn't have a fitting name for this use case and it might be desirable to pass a generic input range instead), but as long as that can be done as incremental improvements, this could be a separate undertaking. The core implementation of all of this should also be in vibe.inet.webform.

Contributions here are certainly welcome!

@vnayar
Copy link
Contributor Author

vnayar commented Mar 14, 2024

I made two initial PRs, both in their early stage of development. Between the original RFCs and Vibe's own architecture, there's a lot going on, so I wanted to get some early feedback to make sure I'm on the right path and not too far off track.

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

No branches or pull requests

2 participants