GZIP Compressed Web Requests in WP7

Before you read on, you might want to read the “Take 2” blogpost instead: https://www.sharpgis.net/post/2011/08/28/GZIP-Compressed-Web-Requests-in-WP7-Take-2.aspx

If you use the WebClient in Silverlight, the browser handles the web request for you, and if the browser supports compressed content (which all of them does), it will take full advantage of that, and you never have to worry about it. However on Windows Phone 7, there is no browser, and the Silverlight API itself handles the web request. However, this client does NOT support compressed content. The result of that is often a much larger response, which in turn means an app that loads data from the web updates much slower, and for those who pay per Mb downloaded, also a big increase in dataplan costs. Data like JSON and XML can sometimes compress as much as 10x, so there’s quite a benefit to compress data responses.

Unfortunately you can’t choose to request compressed content through the header and handle the uncompressing yourself, because the required header (Content-Encoding=gzip,deflate) is a restricted header. This is probably a carry-over from Browser-Silverlight (since there the browser handles this), and for whatever reason this restriction wasn’t removed (this is also the case with the Mango beta release). Not supporting gzip and/or deflate in web requests really seems like a (huge) oversight in Windows Phone. If you agree, please vote for this feature here.

So what to do? Well luckily Mango adds support for Sockets which is basically the core component driving the WebClient. So I ventured into creating my own WebClient subclass, and building custom HttpWebRequest/HttpWebResponse handlers that uses a Socket to request data in gzip format.

You can download the compiled library as well as source code below. It works exactly like WebClient (in fact it’s a subclass of WebClient). However, note that the “OpenWrite” is currently not supported (DownloadString, OpenRead and UploadString are all OK to use).

Example:

   1:  WebClient c = new SharpGIS.GZipWebClient();
   2:  c.OpenReadCompleted += new OpenReadCompletedEventHandler(c_OpenReadCompleted);
   3:  c.OpenReadAsync(new Uri("http://www.google.com"), "TESTSTATE");
   4:   
   5:  ...
   6:   
   7:  private void c_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
   8:  {
   9:      StreamReader reader = new StreamReader(e.Result);
  10:      string result = reader.ReadToEnd();
  11:  }

Note: The library requires SharpZipLib (included in binary).

Comments (2) -

  • Awesome!
    I just thinking whether it is possible to enable this compress feature in FeatureService request in ArcGIS API for Windows Phone? I thought we as api(Esri' api) consumer possibly does not have the ability to add this feature in our app because of we can't change the WebRequest's behavior in TaskBase class , right?
    Looking forward to the next release of our Mapping API to enable this. ThanksSmile
  • Just one more question. As I understand, the Accept-Encoding parameter in Http request header means client could process compressed response from server, so server could return content compressed to client, which is indicated by Content-Encoding parameter in Http response header. This is just one-way compressing from server to client.
    Is there any possibilities to enable compressing request content, which is sending from client to server? If so, how does server understand these compressed request body? As far as I can imagine, if I use ArcGIS FeatureService's SaveEdits() method to upload my editing results to server, specially a lot of features (geometry and attributes) to save, it could be a waste of bandwith if the request content didn't get compressed.
    Or we could expect that our Mapping API could do this compressing job for us at both uploading and downloading ways?
    Thanks.

Pingbacks and trackbacks (5)+

Add comment