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 -~----------~----~----~----~------~----~------~--~---
