Working around the Chrome Data Loading Bug in LightSwitch 2012 RC

With the RC release of LightSwitch 2012, some users have noticed data load (the "red x") problems when using Chrome (and very old versions of Firefox).

The underlying issue is how Chrome asks for data and how the OData libraries that LightSwitch uses respond to those requests.

Chrome appends the "Accept-Charset" HTTP header onto outgoing requests -- even those that come from the Silverlight plugin that hosts the Ligthswitch client.  Specifically, for en-US and English language users, Chrome specifies the iso-8859-1 charset encoding on all outbound requests.

Other browsers have done this in the past; older versions of IE and Firefox also asked for iso-8859-1.  Chrome still does it, and there is an active bug on Chrome to ask them to stop doing it.

(Modern browsers either do not set this header at all, or set it to the value "utf-8", which has emerged as the de-facto internet standard)

When a request asking for Accept-Charset: iso-8859-1 comes into the LightSwitch server, it dutifully responds by sending a response which has an iso-8859-1 charset encoding.

The problem is that the Silverlight platform, upon which the LightSwitch Silverlight client is based, doesn't support this content encoding.  When the client tries to de-serialize the XML payload, it sees the content-encoding is one that it doesn't support, and it throws a client-side exception.  Thus, the red-x.

Chrome is perfectly capable of dealing with utf-8 formatted data -- in fact, the Accept-Charset header allows you to specify a list of acceptable character sets and the browsers preferences for each.  Chrome actually sends over an Accept-Charset header that specifies iso-8859-1 as 1st choice, and utf-8 as second choice.  So if we can make the server somehow return a utf-8 response, everyone will be happy.

Until the proper fix is available, here is a workaround that can be used to do just that.  We'll use the "URL Rewrite" module in IIS to accomplish this.  Specifically, we'll create an in-bound rule that re-writes all requests so that the "Accept-Charset" header is replaced with "utf-8".  This will make it seem like Chrome asked for utf-8 to begin with.

First, open the IIS administration console and use Web Platform Installer to get URL Rewrite 2.0

After Web PI launches, type "URL Rewrite" in the search box and install it.

Next, navigate to the LightSwitch app you'd like to apply the fix to.  I think you can also apply the URL Rewrite rule at the top level of your IIS server, but that's riskier so I don't recommend it. 

Double click on the "URL Rewrite" icon in the IIS management pane.

The first thing we need to do is enable changing of the Accept-Charset header by URL Rewrite.  To do that, we choose "View Server Variables" and then choose "Add".  The name of the server variable is "HTTP_ACCEPT_CHARSET".  The name must be upper case and must have underscores where I've specified them.

Now that we've allowed rules to manipulate the Accept-Charset header, we can create a rule that does the manipulation.  From the main URL Rewrite screen, choose "Add Rules" and then choose "Blank Rule"

First, give the rule a name like "rewrite all requests as utf-8"

For the Match URL, choose "Regular Expressions" and specify ".*" for the pattern. 

Under the Server-Variables tab, choose "Add" and then specify "HTTP_ACCEPT_CHARSET" as the name of the variable, and set its value to "utf-8".  Make sure "Replace" is checked.

Finally, under the "Action" section, choose "Rewrite".  Specify "{UNENCODED_URL}" as the rewrite target, and MAKE SURE TO UNCHECK "Append Query String".

Apply/Save the rule and test your app with Chrome.  If things aren't working, look at the traces with fiddler.

Once you get the basic re-write rule working, you can experiment with the “Conditions” tab to try and narrow the applicability of the rule.  For instance, you may want to target only requests that specify iso-8859-1 encoding on the request.