[stu_k]

Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!

[icebraining]

In 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]

Submitting 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.

[treve]

Yea 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]

I'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]

The 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.