4

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.

int3
  • 12,861
  • 8
  • 51
  • 80

3 Answers3

4

Short answer:

No, most browsers will not compress form data for client requests.

Long answer:

Yes, all browsers allow the client to send compressed form data. But since the browsers wouldn't compress the data for us, we've got to compress it ourselves.

Gzip uses the DEFLATE algorithm, which is publicly available and free to use. What can be done is to compress the form data on the client-side using JavaScript (download a JS Gzip library if you don't want to write one yourself), then send the compressed data to the server through either GET, POST, or PUT using XMLHttpRequest.

If you are in control of your web server, you could simply grab the data and uncompress it. If you are not in control, you will have to follow whatever policies set in place. For example, some web servers may require you to set a specific Content-Type, while others may not support it at all.

Lastly note that if your resource is a file that is already compressed, there may be no advantages in gzipping it. However if your resource is huge uncompressed data (e.g. a forum post of 80000 characters), the advantages are enormous.

Community
  • 1
  • 1
Pacerier
  • 86,231
  • 106
  • 366
  • 634
4

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
  • 19,311
  • 11
  • 41
  • 57
  • 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 Mar 07 '10 at 07:43
  • 3
    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 Mar 07 '10 at 11:51
4

Short answer: No.

See: Why can't browser send gzip request?

Community
  • 1
  • 1
Jason Hall
  • 20,632
  • 4
  • 50
  • 57