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

Mime type of request RequestBody when content is a string should likely not be application/octet-stream #8

Open
vincentjames501 opened this issue Feb 4, 2022 · 2 comments

Comments

@vincentjames501
Copy link
Contributor

It's pretty much always set to application/octet-stream which makes a lot of sense for byte-arrays, files, inputstreams, etc. But for Strings, we should consider following what is done in clj-http?

https://github.com/dakrone/clj-http/blob/3.x/src/clj_http/multipart.clj#L101

Rewriting ->request-body to be a defmulti would be nice too as it would allow people to extend the library more easily to support custom types.

vincentjames501 pushed a commit to vincentjames501/clj-okhttp that referenced this issue Feb 4, 2022
@RutledgePaulV
Copy link
Owner

Agreed about the multimethod for ->request-body

I don't like to assume a content-type of text/plain just because someone handed me a string. The truth is I don't know what's in it, and the best I can honestly tell the server is "here are some bytes". The caller needs to set a content-type header if they want to tell the server something more specific.

@vincentjames501
Copy link
Contributor Author

@RutledgePaulV , I fixed this in #9

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