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

Support Multipart Forms #698

Open
ghost opened this issue Jan 3, 2024 · 1 comment
Open

Support Multipart Forms #698

ghost opened this issue Jan 3, 2024 · 1 comment

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
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.

github-merge-queue bot pushed a commit to knope-dev/knope that referenced this issue Jan 13, 2024
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 <[email protected]>
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

1 participant