views:

130

answers:

2

I've heard how browsers can receive gzipped pages from the server. Can they also gzip form data that they send to the server? And if it's possible, how would I decompress this data on the server?

I'm using AppEngine's webapp module, but a general explanation / pointers to tutorials would be sufficient. I've done some googling to no avail.

+1  A: 

I think that browsers probably can send gzipped form data to the server. I don't know if it is common to do so or not.

The sender would need to make sure to have a Content-Encoding: header with a value that included gzip. The body of the message would then need to be encoded with a gzip encoding, and one can compress / decompress gzipped data in python with the gzip.GzipFile class. I don't know if the gzip module is available on appengine -- if it requires a C-module implementation, then it probably wouldn't be (not sure if it does).

As far as the decoding goes, it's possible that the web machinery that runs before your app-engine program gets any input will decode gzipped content. I've done almost no work with appengine, so I'm not familiar with that sort of detail. It's possible though, that you just don't have to worry about it on the server end...it just gets taken care of automatically. You'd have to check.

It might be useful to look at RFC2616, especially the sections for Accept-Encoding and Content-Encoding.

Matt Anderson
AIUI, RFC2616 is about server to client communication. I've tried to answer this question myself (I have an app where clients send the server a large amount of highly compressable data), but not gotten a satisfying answer. There are LZW implementations in JS, but they seem quite slow. I don't know of an out-of-JS way to handle this at all; AFAICT browsers only implement gzip *decoding*.
Sai Emrys
The HTTP RFC covers both directions. Content-Encoding is a permissible header for the client to supply, but I'm not aware of any clients that actually do attempt to gzip post data. You can try it to see if App Engine supports it, though - the RFC says: "If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type)."
Nick Johnson