-
Notifications
You must be signed in to change notification settings - Fork 12
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
File uploads / content-type: multipart/form-data #25
Comments
Thanks @knubie for reporting this. I think there's a few sides to this. Currently we accept a string body as being already encoded, but js/fetch also accepts a FormData, and (I assume?) a Blob, so it makes sense to detect those and not further try to encode them. It doesn't really make sense to encode a FormData or Blob to Transit anyway. That seems like a no-brainer change to me, it's potentially a breaking change, but I don't see how anyone could be meaningfully relying on the current behavior for FormData or Blob as body (or am I missing something? are there cases where this would make sense? perhaps people have set up custom Transit writers/readers for these types, that could happen...) I'm also not against introducing something like I think it also makes sense for people to want to separately decide the encoding, and the content-type header. E.g. serializing as json, but have a more specific content-type like Ideally a high level library like this would relieve people from having to deal with FormData objects directly. POSTing a file/blob seems common enough that we can support it directly. I'm thinking fetch could introduce a (fetch/post "/foo" {:content-type :multipart-form-data
:body [{:content-type "application/json" ;; string or keyword, so e.g. :json or :transit+json also works
:content-disposition "my_file.json"
:content blob-or-string}]}) Does that all make sense @knubie ? Patches for these things are welcome, as is further comments to make sure what we're planning to do makes sense and doesn't have adverse side effects for existing users. Thanks! |
I think I agree with pretty much everything you've said here. I know that |
At the moment it doesn't seem possible to send files as
multipart/form-data
as described here: Using the Fetch API - Web APIs | MDN.For example with
js/fetch
we could do something like this:and
js/fetch
will automatically set theContent-Type
header tomultipart/form-data
and encode the body properly.However in lambdaisland/fetch the body is always encoded according to the
:content-type
option before it's passed tojs/fetch
(unless it's a string):fetch/src/lambdaisland/fetch.cljs
Lines 102 to 104 in 1fe9fab
There isn't really a way to leave the body decoded without passing a string.
I think the simplest workaround would probably be to add a new
:raw
ornil
option for:content-type
that just passes the:body
through tojs/fetch
decoded.It's possible to bypass the encoding today by using
:default
as the:content-type
, but that will also explicitly set theContent-Type
header tonil
, since it's not in thecontent-types
map and is really just a hack for the encoding multimethod.fetch/src/lambdaisland/fetch.cljs
Lines 80 to 81 in 1fe9fab
The text was updated successfully, but these errors were encountered: