Going to server side - UploadedFile represents already decoded data - where is file-data parsing realized from multipart data - we have acces to raw data? F.e. for saving very big files uploaded in chunks or any custom handling?
So, first of all, tink_web allows posting data with different content types and will use the content-type to pick the right one. I’m surprised that the request even works without content-type header, but maybe I put in some automatic fallback that I forgot about
You can use multipart/form-data
on the server, assuming you compile with -lib tink_multipart
or you’re on php/neko or some other environment that parses multipart anyway. If this is the case, you will get a FormFile
which has a read
and a saveTo
method, to either stream the file or save it to a location of your choice. Looking at the code it seems like the parsers in tink_multipart
put the files into memory, rather than into tmp files - something to be aware of when it’s tink_web handles multipart processing (as opposed to Apache/nginx). On the plus side, body parsing starts after routing and after authentication. And if you really need to put through enormous amounts of data my suggestion would be to define body:RealSource
and then you can stream the body wherever you want to.
On the client side you can of course construct these multipart request in any imaginable way. You can have a plain html form. You can use whatever native APIs are around (e.g. use XHR with FormData). You can use tink_http directly as Tom did, in which case you’ll want to use new tink.Multipart()
(again requires -lib tink_multipart
) to construct the request body correctly.
Alternatively, you can let tink_web handle all of the client side request construction for you (regardless of whether the server actually uses tink_web or not). It keeps all the tedious parts out of the way.
You can post files to tink_web endpoints while using JSON for your request body. Whether or not that is appropriate is for the caller to choose. The Remote
(i.e. the client end of tink_web) will always prefer JSON if available - you can disable JSON for a route by setting @:accepts('multipart/form-data')
.
FormFile shouldn’t be an abstract for form encoded data?
It has JsonFileRep but it contains binary data field, not directly JSON-able - ofBlob shouldn’t encode it for us? This way Json.stringify( f: fileForm ) should work as expected.
For JSON, tink_web relies on tink_json which handles binary data transparently (through base64). The JsonFileRep
is used to tell tink_json how to represent a FormFile
: a name, a type and the binary content (which again it knows to represent as its base64 encoded counterpart). FormFile
is there to create a common type to represent files that works for both multipart and json. That’s also why always base64 encoding the payload is not an option.