The compression is standard HTTP compression when seen from the client. As I understand (but I'm not an authority in this domain), if you use the Android HTTP stack, the decompression will happen transparently for you.
If you're rolling out your own HTTP code you'll have to do the decompression yourself, but the proxy should only send you compressed data if you advertise that you support it (in your request headers), and you should advertise it if you don't support it. JBQ On Wed, Dec 3, 2008 at 2:16 PM, melody <[EMAIL PROTECTED]> wrote: > > Hi Jean-Baptiste Queru, > > Thanks for the info. Just wanted to clarify a minor point. > > When you say that the data is compressed when it is sent over the air, > are you saying that the compression and decompression happens at a > layer that I never see? Is the Android OS handling the decompression > of the incoming data that so that when I look at it in the SDK, it's > already decompressed for me? > > Thanks. > > > > Jean-Baptiste Queru wrote: >> It's actually not uncommon in the cell world to turn off compression >> on the public Internet, so that the proxy can have an easier time >> looking at the data and processing it to send it over the air (where >> it is compressed), i.e. trading Internet bandwidth for some CPU time >> on the proxy. >> >> JBQ >> >> On Tue, Nov 25, 2008 at 10:53 AM, melody <[EMAIL PROTECTED]> wrote: >> > >> > Thanks. I ran the test in the emulator, and the http compression was >> > kept. So this does indeed seem to be a problem being caused by a >> > proxy at T-Mobile. >> > >> > Not to be overly dramatic, but isn't this a pretty serious issue? I >> > would think that under 3G, T-Mobile would very much want us all to be >> > using HTTP compression so that we don't flood their network. Even on >> > my home broadband connection, when I turn off http compression in my >> > browser to do testing work, most websites load much more slowly, >> > especially with the massive css/js files being transmitted these >> > days. >> > >> > Something else that may or may not be related: >> > I noticed that the T-Mobile proxy is also converting my http request >> > to a "HTTP 1.0" request, whereas I am actually trying to send a "HTTP >> > 1.1" request. >> > >> > >> > >> > >> > David Turner wrote: >> >> The best way to test this is try to run your test from the emulator, since >> >> the browser >> >> wouldn't then use an intermediate T-Mobile proxy. >> >> >> >> On Tue, Nov 25, 2008 at 12:27 AM, melody <[EMAIL PROTECTED]> wrote: >> >> >> >> > >> >> > I've been working on improving the speed of my application and noticed >> >> > that when I turn off wifi and use the 3G connection, http requests no >> >> > longer use http compression. >> >> > >> >> > Specifically, when using the 3G connection, the "Accept-Encoding" >> >> > header (which I have set to "gzip, deflate") are stripped off before >> >> > the request arrives at my server. I tested this with the HttpClient >> >> > class, and with my own custom http client through java.net.Socket. >> >> > >> >> > I then also verified this using the native android web browser. With >> >> > wifi turned on, my server recieves a header "Accept-Encoding: gzip". >> >> > With wifi turned off, and using the 3G connection, my server does not >> >> > receive that header. >> >> > >> >> > I initially thought this might be an intentional behavior as part of >> >> > 3G connections, but then I tested it with a 3G iphone (on AT&T), and >> >> > there was no such problem there. So I'm guessing it's a problem >> >> > specific to T-Mobile. i wonder if there is some proxy that is >> >> > intentionally stripping out this header. >> >> > >> >> > I'd appreciate any advice about this. For an XML-based web service >> >> > like mine where the response data has a high compression ratio, this >> >> > behavior causes a significant speed hit. >> >> > >> >> > > >> >> > >> > > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
