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