A disturbing trend

Today I was reading through the list of speakers for an upcoming conference on software design, user interaction, etc. It seems that everyone there is working for some company with a cool “web 2.0” name that does something social and collaborative.
Call me stupid, but looking at these companies’ websites I really don’t understand what they do. I mean what they produce. I mean what they sell to pay the bills. The buzzword-meter is at the top end of the scale, but I still don’t get it.

Maybe in two years I will read this post and realize I was wrong (as usually) –for now my buzzword-meter and my BS-meter are very closely related.


Edit: it seems that these people think that social networking will produce huge sales in the next years. You can download the full report here. Yes, the PDF download costs $1749. Maybe I start understanding…

Gzip compression between WCF web service and Silverlight

Update (12/1/2009): this seems not to work anymore. I’m still investigating on the cause as it was definitely working (I even performed some comparison benchmarks for our product) –or maybe I had some kind of hallucinations, it happens too.
If you have any idea please share in the comments below! Thanks!

Please read this post for a working solution.

The scenario is the following: you have a Silverlight 3 application that consumes a WCF web service. By default the data exchange is serialized in XML, thus the network payload quickly becomes high if your web service sends significant amounts of data.

XML content is a very good candidate for zip/gzip compression, so it’s logical to look in this direction.
The bad news is that I found no documentation or forums/blog entries about this particular case, so it took me a while to find the solution. I even played with the compression encoder WCF sample only to find that it’s done the way it is because it refers to a different scenario (but I learned a lot in the way).
The good news is that the solution is so simple it’s not even funny, that’s probably why nobody explains how to do it.

HTTP Content-Encoding

Most modern web servers support compression and so do most browsers. When you browse the web, you often receive compressed content even if you don’t notice anything.  You can use Fiddler2 to realize this fact.

How it’s working: the browser tells the server what kinds of compression he supports by setting the Accept-Encoding HTTP header. For example with

Accept-Encoding: gzip, deflate

a browser is saying “I can read content compressed with the gzip or deflate algorithms”. The server then decides what is best depending on several factors (for ex. the kind of data he’s sending). If he opts for compression (let’s say gzip), he compresses the content and adds this HTTP header to the response:

Content-Encoding: gzip

The browser now knows that the content is compressed and decompresses it with the appropriate algorithm before giving it to the html parser or whatever.
This is exactly the mechanism we will leverage.

Client Side (Silverlight)

Let’s see how to prepare the client-side.
We have to do two things: 1) tell the server we support compression 2) decompress responses if they are compressed.

How? The browser does all this for you. That’s simply because any web server call made by Silverlight is handled (by default) by the browser’s HTTP stack. This means that the browser manages all the low level stuff such as adding the proper Accept-Encoding header and decompressing content based on Content-Encoding.
The whole process is completely transparent to Silverlight: we don’t have to do anything.

Wonderful, but since compression is still not happening it means we have to do something on the server.

Server Side (WCF)

Here we have to distinguish two cases: the service can be hosted in IIS or self-hosted. If it’s hosted in IIS you’ll just have to enable compression in the IIS control panel.

In my case however the service is self-hosted.
The key here is the endpoint’s binding. Silverlight 3 only supports basicHttpBinding, so your WCF service probably uses the same (as they must match). The problem is that basicHttpBinding is “basic” indeed, and cannot do advanced things like handle compression.

The trick is to use a more “advanced” binding that can handle http compression but is still compatible with the client’s basicHttpBinding. Here is a customBinding that mimics the basicHttpBinding:


<binding name=customHttpBinding>

<textMessageEncoding messageVersion=Soap11Addressing1

<httpTransport />



the same in c#:

var customBinding = new CustomBinding(

new TextMessageEncodingBindingElement(



new HttpTransportBindingElement());

That’s all. Yes, nothing more is needed! This binding will automatically deal with compression the same way as IIS does.
You can fire up Fiddler2 and look at your web service calls. You can play with the Accept-Encoding header and see that the server behaves accordingly.

Maybe in some future version Silverlight will support more advanced bindings, in that case you won’t probably even need this.

Two Silverlight 3 Gotchas

I’m recently working quite a bit with Silverlight 3 and here are a couple of weird problems I encountered. They are easy to solve, but I hope this post will save you some head scratching.

Gotcha #1 – Vertical scrollbar in IE8

When Visual Studio 2008 generates a test page for your Silverlight application, it creates an <object> tag with width and height set to 100%.

When you look at that page in any browser other than IE8 everything is working fine: the Silverlight control takes the whole page –no scrollbars. Now if you open your website in IE8 you may notice a vertical scrollbar and a small white space below your Silverlight control.


Let’s look at the html generated by Visual Studio. Near the end there are these lines:

   76         </object>

   77       <iframe id=’_sl_historyFrame’ style=’‘></iframe>

   78     </div>

   79   </body>

   80 </html>

Nothing suspect at first sight. However, the problem is right there: it seems that IE8 allocates some vertical space for the whitespaces/tabs/newlines between the closing tags.
The solution is easy: you can either remove the spaces/newlines:

   77   <iframe id=’_sl_historyFrame’ style=’‘></iframe></div>

   78 </body>

   79 </html>

or change the embedded style and set overflow to “hidden” instead of “auto”:

    7 <style type="text/css">

    8 html, body {

    9     height: 100%;

   10     overflow: hidden;

   11 }

Gotcha #2 – “GET silverlight 3” Badge in Firefox 3.5

There is a neat way to pass startup parameters to Silverlight from the host html page. You can specify them inside the initParams tag. For example:

   67 <object data="data:application/x-silverlight-2">

   68     <param name="initParams" value="param_1=a; param_2=b" />

However, if you don’t have any parameter, you may be tempted to just leave the value attribute empty:

   68 <param name="initParams" value="" />

Don’t do it. For some reason, Firefox 3.5 has a problem with that empty attribute and instead of loading your application will believe that the Silverlight runtime is not installed. Your page will show the nice “Install Silverlight” image and will not request any xap file.

The solution is again pretty simple: if you don’t have any parameter you can completely remove the whole tag or put in some random characters (assuming that they won’t mess with your Silverlight app). And no, a single space won’t work.

Pretty dumb, I know…