3 Replies Latest reply on Jun 19, 2008 1:16 PM by blahxxxx

    Adobe Air needs HTTP gzip compression


      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.



        • 2. Adobe Air needs HTTP gzip compression
          adobe_paul Adobe Employee
          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:


          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.
          • 3. Re: Adobe Air needs HTTP gzip compression
            blahxxxx Level 1
            Thanks for the reply Paul. Much appreciated.

            HTTP GZIP compression is really a big gap in the functionality of AIR however.

            It's just essential - it's really not practical to build apps that rely on web services/SOAP without over the wire GZIP compression.

            It's really something that should be built into the platform, not something we should have to deal with in the application.


            Andrew Stuart