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