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.

Sign up for GitHub

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

Jump to bottom

Support Multipart Forms #698

Open
ghost opened this issue Jan 3, 2024 · 4 comments
Open

Support Multipart Forms #698

ghost opened this issue Jan 3, 2024 · 4 comments
Labels
help wanted Extra attention is needed

Comments

@ghost
Copy link

ghost commented Jan 3, 2024

Currently I cannot find any support for sending multipart Form data (multipart/form-data), It would be great If that was possible.
@ghost ghost mentioned this issue Jan 3, 2024
Merged
8 tasks
@johan-bjareholt
Copy link
Contributor

It's quite easy to do youself, just:

  1. generate a random boundary
  2. Set HTTP content type header with said boundary like this "multipart/form-data; boundary={}"
  3. For each part, loop this to create the HTTP body
    • write start delimiter --BOUNDARY
    • write "Content-Disposition" header and other optional HTTP headers for this specific part
    • write \r\n\r\n to end header section
    • write part body
    • write \r\n
  4. Write ending boundary --BOUNDARY--

I have done this, but it is unfortunately not open source and has multiple very specific details that only fits my rare use-case so it's not really suitable for upstreaming.

@dbanty dbanty mentioned this issue Jan 13, 2024
Open
github-merge-queue bot pushed a commit to knope-dev/knope that referenced this issue Jan 13, 2024
@siblingsofthevoid @dbanty
Add gitea support (#759)
b2712e7 
Took me a little longer, since i noticed that my initial idea would
literally have required a full refactor, which was a little too large in
scope. the above checklist is for keeping track of what will be added
and this PR is here to track the progress and eventual questions.

closes #743

## Plans
- [x] Extending the configuration format and adding a `[gitea]` section
- [x] Allowing to generate the configuration from known gitea remotes
- [x] using gitea on the `CreatePullRequest` step
- [x] using gitea on the `Release` step
- [x] creating a new step `SelectGiteaIssue`
- [x] adding a new `forge` concept to the documentation to link forge
integrations together in a convenient place
- [x] adding a new `gitea` section to the config file reference
- [x] multi-forge support as mentioned in
#743 (comment)

## Testing

- PR generated by knope on a copy of one of the projects i work on.
(fixes will be pushed in a bit)
https://codeberg.org/FallenValkyrie/testing/pulls/5
- generated release
https://codeberg.org/FallenValkyrie/testing/releases/tag/v0.3.0
- Adding tests in `tests::gitea_release` and `tests::generate`
- selecting gitea issues (token has already been deleted, so no need to
censor it)
![An image showing knope successfully selecting gitea
issues](https://github.com/knope-dev/knope/assets/42149402/3e538d1a-ccdb-4b74-92f3-868070af8dc6)
- Using the same testing repo to see if knope correctly asks for the
`GITEA_TOKEN`
![An image of a Knope prepare-release workflow doing a lot of things and
then asking for the Gitea
token](https://github.com/knope-dev/knope/assets/42149402/dc849e58-20b6-4d18-8a0d-244f0d0ecd8a)



## Notes
- Commits will be reorganized after review. This is simply because i
don't feel like constantly reorganizing commits.
- The PR looks huge, but most of that is tests and test assets.
- Currently `ureq` (as far as i can tell) doesn't support sending
multipart form data and the only library i could find,
[`ureq_multipart`](https://docs.rs/ureq_multipart/latest/ureq_multipart/index.html),
panics on IO errors and has messages in chinese (see [in its own
codebase](https://gitee.com/eshangrao/ureq-multipart-toolkit/blob/master/src/lib.rs#L186-196)).
Together i find those unacceptable design choices. issue:
algesten/ureq#698

---------

Co-authored-by: Dylan Anthony <dbanty@users.noreply.github.com>
@robin-nitrokey robin-nitrokey mentioned this issue Jul 22, 2024
Open
@Tienisto Tienisto mentioned this issue Aug 23, 2024
Open
@algesten
Copy link
Owner

This needs doing for ureq 3.x as well. Let's study the API in reqwest (and others?). Maybe behind a feature flag depending on how messy it becomes.

Help wanted.

@algesten algesten added the help wanted Extra attention is needed label Nov 26, 2024
@TristanWasTaken
Copy link

Let's study the API in reqwest (and others?)

#120 (comment)

I like that reqwest accepts multiple input types (reader, bytes) and not just a reader.

@algesten
Copy link
Owner

Yeah. That's neat. We should be able to reuse the AsSendBody trait for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@algesten @johan-bjareholt @TristanWasTaken