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-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)
... 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"
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
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.
10 Sep 2008
Excellent post...Just what i needed. Cheers!