If you are doing socket based communication to an HTTP server and tell it that you accept gzipped data then you'll get back gzipped data if it supports it.
If the network (T-Mobile's proxy) thinks that's a bad idea and removes your accept gzip header then you won't get back gzipped data. If the network does any compression of its own then it will compress and decompress and a low level that you and the TCP/IP stack will not see. I'm still curious what happens when you try a different port than 80. On Dec 3, 3:24 pm, melody <[EMAIL PROTECTED]> wrote: > Thanks for the suggestion. > > "Content-Type: text/xml; charset=utf-8" is what I get in the response > header. > > Just as a test, I tried sending back "Content-Type: text/html" > instead, but that didn't change anything with regards to compression. > > Jean-Baptiste Queru wrote: > > I'm not familiar enough with the low-level protocols used in 2G or 3G, > > so I don't know whether there's any compression happening at that > > level. It sounds like the data is indeed not recompressed by the proxy > > at the HTTP level (even though I believe that such compression would > > be beneficial). > > > What is the MIME type of your response? It's possible that the proxy > > only compresses html, javascript and css and leaves everything else > > alone. > > > JBQ > > > On Wed, Dec 3, 2008 at 2:57 PM, melody <[EMAIL PROTECTED]> wrote: > > > > I was doing my testing with my own custom written http client (based > > > on Java.net.Socket). In all tests, I sent a Accept-Encoding: gzip, > > > deflate header. > > > > The data I was receiving back from my server was not compressed when > > > using 3G, but it was compressed when I was using wifi (which doesn't > > > cause any problems, I just have to decompress it manually as you > > > suggested). > > > > This is why I was concerned that the data was not actually being > > > compressed over the air. If I'm not using the "Android HTTP stack", > > > and I see uncompressed data from the socket's inputstream, does that > > > mean the data was actually transmitted uncompressed over the air? > > > > Or is there some other compression/decompression layer when using a 3G > > > connection that has been abstracted away from the SDK? > > > > Jean-Baptiste Queru wrote: > > >> 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 -~----------~----~----~----~------~----~------~--~---
