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 for Content-Type on each part of a multi-part form #1050

Open
1 task done
bowlofeggs opened this issue Mar 30, 2021 · 3 comments
Open
1 task done

Support for Content-Type on each part of a multi-part form #1050

bowlofeggs opened this issue Mar 30, 2021 · 3 comments
Labels
enhancement New feature or enhancement needs product design We like the idea, but we want to explore the problem deeper, and consider the solution holistically

Comments

@bowlofeggs
Copy link

Checklist

  • I've searched for similar feature requests.

What enhancement would you like to see?

I would like to be able to do the equivalent of this curl command:

$ curl -v -X PUT https://example.com/ -F "metadata={some: data};type=application/json" -F "file1=@some/file.binary;type=application/octet-stream"

Using curl's --trace-ascii feature, the above results in something like this:

0000: PUT / HTTP/1.1
001e: Host: example.org
0034: User-Agent: curl/7.74.0
004d: Accept: */*
005a: Content-Length: 1014
0070: Content-Type: multipart/form-data; boundary=--------------------
00b0: ----b0115f32bd629a31
00c6: 
=> Send data, 1014 bytes (0x3f6)
0000: --------------------------b0115f32bd629a31
002c: Content-Disposition: form-data; name="metadata"
005d: Content-Type: application/json
007d: 
007f: {some: data}
008d: --------------------------b0115f32bd629a31
00b9: Content-Disposition: form-data; name="file1"; filename="file.binary"
00fb: Content-Type: application/octet-stream
0123: 
0125: Some bytes here
03c8: --------------------------b0115f32bd629a31--

I've attempted a few things with httpie, but I don't see a way to get the application/json component to come through on the other end. Is this possible?

What problem does it solve?

It allows each part of a multi-part form to have its own Content-Type.

@bowlofeggs bowlofeggs added enhancement New feature or enhancement new Needs triage. Comments are welcome! labels Mar 30, 2021
@jkbrzt
Copy link
Member

jkbrzt commented Mar 31, 2021

HTTPie supports this use case, but it only allows you to specify the type when you load the contents from a file (i.e., it doesn’t currently support specifying the type for string fields).

This would be the equivalent:

# Prepare files to upload:
$ echo json > /tmp/test.json
$ echo binary > /tmp/test.bin
# Make request:
$ http --offline --multipart PUT example.com \
    'metadata@/tmp/test.json;type=application/json'  \
    'file1@/tmp/test.bin;type=application/octet-stream'
PUT / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 340
Content-Type: multipart/form-data; boundary=eba2bec894024119814db278f9dd5da1
Host: example.com
User-Agent: HTTPie/2.4.0

--eba2bec894024119814db278f9dd5da1
Content-Disposition: form-data; name="metadata"; filename="test.json"
Content-Type: application/json

json

--eba2bec894024119814db278f9dd5da1
Content-Disposition: form-data; name="file1"; filename="test.bin"
Content-Type: application/octet-stream

binary

--eba2bec894024119814db278f9dd5da1--

@jkbrzt jkbrzt removed enhancement New feature or enhancement new Needs triage. Comments are welcome! labels Mar 31, 2021
@bowlofeggs
Copy link
Author

Oh interesting, I hadn't considered doing it that way. I think that's an acceptable way to do it, though it might be nice to have a way to do it as an inline argument on the CLI too.

Feel free to close this issue if you aren't interested in supporting it as an inline argument.

@bowlofeggs
Copy link
Author

I did realize that there is one way that using the file to upload the JSON is not quite equivalent to sending it the way curl does. It ends up including the filename, as you noted above. For my current purposes this is fine, but I thought I'd note that here just for completeness.

@isidentical isidentical added enhancement New feature or enhancement needs product design We like the idea, but we want to explore the problem deeper, and consider the solution holistically labels Dec 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or enhancement needs product design We like the idea, but we want to explore the problem deeper, and consider the solution holistically
Projects
None yet
Development

No branches or pull requests

3 participants