Upstream compression in an era of renewed bandwidth constraints

[GreenReaper]

Most competent webmaster appreciate the benefits of HTTP compression.
But one thing I'd like to see more work on is upstream compression
(or, from a web-server point of view, input decompression) - the
reverse of standard HTTP compression. Apache 2.x actually has the
ability to do this, but no browsers support it, and so few servers
enable it:
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#input
https://bugzilla.mozilla.org/show_bug.cgi?id=463089

Implementing multipart/form-data x-compress might be another
worthwhile step:
https://bugzilla.mozilla.org/show_bug.cgi?id=236083

A specific use case is the submission of edits to Wikipedia. Editing
involves a repeated series of previews, each of which requires
submission to the server to guarantee correct formatting and
readability. Waiting for the submission to complete can lead to
significant delay with larger documents. Arguably, improvements should
be made within the application to reduce the need for such previews;
but an edit still needs to be sent at least once, and it would be
great if the server could add a standard tag indicating that the
submission could be sent compressed.

Issues like TCP slow-start and connections with limited upstream
bandwidth are likely to continue to constrain raw performance in this
area. We need to be smarter about what we send from the client, as
well as from the server.