问题
I have a Silverlight project getting data from an IIS 7.0 server via WCF web services. The data returned is usually large, so compression seemed like a good option. However, for the life of me, I can't get it to work.
Here's what I tried so far
- Enabled compression (dynamic and static) for all mime types (/). Verified that it works (a hit on an aspx page returns gzipped data as per fiddler)
- Did a whole lot of digging around on WCF and compression. I read something along the lines of WCF 4.5 having something to enable / disable gzip. I'm not sure if this means that IIS 7.0 dynamic compression cannot be used, or if its something unrelated.
- Also got a few examples on using GZipEncoder (from Microsoft WCF Samples)
And here's what I'd like to find out
- With Silverlight reading data from WCF hosted on an IIS 7.0 server with .NET 4.0, is it possible to turn on compression for the XML responses by simply messing around with the Web.Config / applicationHost.Config?
- If not, what is the easiest way to get it to work (say, add a dll, change my Web.Config and done!)
Thanks folks!
Edit: Thanks for all the answers folks. Just one quick note - if someone can confirm that it does not work for WCF 4.0 "or" works with WCF 4.0 only if you do this, that'd help.
回答1:
We've got GZip compression working for WCF, I'll try to backtrack what we did to get it working. There are a few gotcha's which might bite you trying to get this to work (personally I'm moving trying to move away from WCF wherever possible).
Firstly you need to have IIS Dynamic Compression installed. Secondly you must use browser http in the Silverlight app (which is the default in browser, but not when running OOB) since the build-in http stack doesn't support GZip compression. You can force this in the Application_Startup() function (change http to https if required).
WebRequest.RegisterPrefix("http://", System.Net.Browser.WebRequestCreator.BrowserHttp);
The gotcha here is that you will only ever get generic errors in your client when a webservice call fails because the browser stack doesn't pass the content of an http 500 response on to Silverlight. Is this is an issue for you it can be worked around with a custom MessageInspector which changes the response code to 200 always.
In your web.config you need to enable dynamic compression
<system.webServer>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
On top of that you need to have the mime type registered in IIS, we added this to the applicationHost.config for WCF with binary message encoding.
<add mimeType="application/soap+msbin1" enabled="true" />
If your not using binary message encoding you probably need application/soap+xml instead here. If I recall correctly these are all the steps needed.
The last gotcha though, it doesn't help when your client is sending large messages since there is no way (afaik) to make silverlight actually send gzip compressed requests to the server, so your only gain will be on the data send by the server.
回答2:
There are several options for compression with WCF over HTTP. Each have their advantages and disadvantages.
IIS dynamic compression
This is compression on the HTTP layer, and is the most performant, since it runs at the lowest level. It is also the most standard, thus will work with other web technologies easily.
Unfortunately the main disadvantage is that it was based on old web technology (HTTP) where there was the old belief that upstream data is limited and only downstream payload is worth compressing. Therefore upstream data isn't compressed.
Message Compression
Starting with .net 4.5 the message encoders have a new property on MessageEncoder to allow you to enable compression. This is done on the .net layer, and thus is much slower than IIS compression. It is also proprietorial and thus can be difficult to use with non-dot-net technologies. This tech is not availible for SilverLight.
来源：https://stackoverflow.com/questions/19201982/getting-iis-gzip-compression-to-work-with-silverlight-wcf-service-on-net-4-0