8 ms·
Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!
by stu_k 12y ago
Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!
- treve 12y agoYea this makes me wish there was a better way to deal with this. JSON is popular because it's simple, but as a result sucks for a bunch of use-cases.
- tonyarkles 12y agoI'm mobile so don't have a good way to just test this myself... Any idea how good/bad base64+gzip is (ie gzipping the json before submitting it)? If it's within a few percent then this probably isn't a bad solution!
- dnet 12y agoThe browser doesn't gzip _requests_ by itself, only the server does so with the _response_ if the user-agent (including browsers) states that it supports such content encoding. Of course you can implement gzip in JavaScript, but if you do that, you can already mangle the request and send the file to the server without Base64 encoding.
- icebraining 12y agoIn fact, HTML already has a solution for that in the form of multipart/form-data. Instead of encoding the files directly inside JSON, you could add them as extra parts of the MIME message, and just have a reference in the JSON value (as in email, which uses a "cid:<part-identifier>" URI to inline images as such, as described in RFC2392). You'd still need special support on the server, though.
- Silhouette 12y agoSubmitting files with this form encoding is of course going to have the base64 overhead HTTP connections typically use compression with any modern browser and server, so there is likely to be little overhead in practice.