Skip Navigation LinksHome > View Post

Web Service XML compression with .NET 2.0

Compressing content before sending it over the wire can significantly reduce download times and XML is the perfect candidate for compression because of its repetitive nature.

In .NET 1.x, using HTTP Compression with Web Services you could override the GetWebResponse and GetWebRequest in a custom SoapHttpClientProtocol class and do the decompression in your own custom WebResponse class (as described in this article).

However, .NET 2.0 has built in decompression capabilities for Web Service clients, so the work is done for you.

I recently released a new Web Service and enabled IIS 6's HTTP compression feature to reduce the amount of bandwidth burned by the service. Naturally, I wanted to make sure that compression was working.

So I used Ethereal, which is an excellent packet sniffer. I was stunned to find that the Web Service was not sending compressed XML - I could plainly see the XML traveling across the wire. However, a closer look at the exchange of HTTP headers indicated the source of the problem. This is what the request header looks like if I request the WSDL in Internet Explorer:

GET /clientservice.asmx?WSDL HTTP/1.1
Accept: */*
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: host
Connection: Keep-Alive

... and this is what the request header looks like when making a call to the Web Service using my Web Service client (a proxy class derived from HttpWebClientProtocol):

POST /ClientService.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.42)
Content-Type: text/xml; charset=utf-8
SOAPAction: "soap action"
Host: host
Content-Length: 1568
Expect: 100-continue
Connection: Keep-Alive

Notice the absence of Accept-Encoding: gzip, deflate when making a call to the service through the proxy. I immediately realised that something was wrong and referred to the documentation on MSDN. The HttpWebClientProtocol class has an EnableDecompression flag which defaults to true according to the documentation. I however found that this is not correct. The default is false. I therefore set the flag to true in my web service proxy and bingo, my web service dished up some nicely compressed content.

On the note of documentation errors Anders NorĂ¥s has an interesting article describing more erroneous MSDN documentation.

Tags: Xml

 
Bruusi Post By Bruusi
1:28 AM
30 Nov 2005

» Next Post: Localizing Site Map data in ASP.NET 2.0
« Previous Post: Failed to map the path App GlobalResources

Comments are closed for this post.

Posted by Lars @ 10 Sep 2008 6:21 AM
Excellent post...Just what i needed. Cheers!

© 2005 - 2014 Josh Twist - All Rights Reserved.