Adobe Air needs HTTP gzip compression

Question

Hello
We are developing an Adibe Air application. We use SOAP for
service calls and we depend entirely upon gzip HTTP compression to
make the network performance even vaguely acceptable. SOAP is such
a fat format that it really needs gzip compression to get the
responses down to a reasonable size to pass over the Internet.
Adobe Air does not currently support HTTP gzip compression
and I would like to request that this feature be added ASAP. We
can't release our application until it can get reasonable network
performance through HTTP gzip compression.
Thanks
Andrew

Answer 1

Hi blahxxxx,
Sorry for the slow reply -- I wanted to take some time to try
this out rather than give an incomplete response.
It's not built into AIR, but if you're using
Flex/ActionScript for your application you can use a gzip library
to decompress a gzipped SOAP response (or any other gzipped
response from a server -- it doesn't have to be SOAP). Danny
Patterson gives an example of how to do that here:
http://blog.dannypatterson.com/?p=133
I've been prototyping a way to make a subclass of the Flex
WebService class that has this built in, so if I can get that
working it would be as easy as using the Flex WebService component.
I did some tests of this technique, just to see for myself if
the bandwidth savings is worth the additional processing overhead
of decompressing the gzip data. (The good news is that the
decompression part is built into AIR -- just not the specific gzip
format -- so the most processor-intensive part of the gzip
decompression happens in native code.)
Here is what I found:
I tested this using the
http://validator.nu/ HTML validator
web service to validate the HTML source of
http://www.google.com/. This
isn't a SOAP web service, but it does deliver an XML response
that's fairly large, so it's similar to SOAP.
The size of the payload (the actual HTTP response body) was
5321 bytes compressed, 45487 bytes uncompressed. I ran ten trials
of each variant. All of this was done in my home, where I have a
max 6Mbit DSL connection. In the uncompressed case I measured the
time starting immediately after sending the HTTP request and ending
as soon as the response was received. In the compressed case I
started the time immediately after sending the HTTP request and
ended it after receiving the response, decompressing it and
assigning the compressed content to a ByteArray (so the compressed
case times include decompression, not just download). The average
times for ten trials were:
Uncompressed (text) response: 1878.6 ms
Compressed (gzip) response: 983.1
Obviously these will vary a lot depending on the payload
size, the structure of the compressed data, the speed of the
network, the speed of the computer, etc. But in this particular
case there's obviously a benefit to using gzipped data.
I'll probably write up the test I ran, including the source,
and post it on my blog. I'll post another reply here once I've done
that.