[android-developers] Re: HTTP compression lost when using 3G connection
Hi All Can we connect wireless device in from Android Browser using Socket Programming?? Thanks in Advance --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
If by "Browser" you mean "the web browser on an Android device" then no, it's just a web browser. But of course you can write your own application for Android that does TCP/IP sockets to connect to some other service. (also, maybe post a new thread next time?) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
There's an issue where downloading small files (such as small 20Kish apps) get corrupted over 3G, but not wifi, that this is certainly related to. If you've ever downloaded an app, and it says that it wants to replace "Android System", that's the bug, and I now blame T- Mobile (as opposed to Google) for it. -- Eric On Nov 25, 1:58 pm, Jean-Baptiste Queru <[EMAIL PROTECTED]> 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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
I haven't had much experience with T-Mobile 3G, but plenty with 2G (US). It appears that T-Mobile expects traffic on port 80 to be HTTP so I'm guessing that they add further filtering and optimization based on that expectation. If they are already compressing the data it would (conceivably) make sense to pull gzip accept headers so there isn't double compression. I would suggest trying a different port than 80 and would be very surprised if they were able to yank HTTP headers of off data running over an arbitrary socket. When it comes to port 80 I've seen non-HTTP traffic simply not go through. On Nov 24, 3:27 pm, 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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
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
[android-developers] Re: HTTP compression lost when using 3G connection
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
[android-developers] Re: HTTP compression lost when using 3G connection
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 > >> >> >
[android-developers] Re: HTTP compression lost when using 3G connection
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 > > >
[android-developers] Re: HTTP compression lost when using 3G connection
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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
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 -~--~~~~--~~--~--~---
[android-developers] Re: HTTP compression lost when using 3G connection
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 -~--~~~~--~~--~--~---
