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.

Comments

• Anonymous
  June 25, 2012
  Thanks Matt. Is there a similar work around to LightSwitch apps deployed to Azure? Paul

• Anonymous
  June 26, 2012
  Paul: I haven't tried it, but msdn.microsoft.com/.../dd573358.aspx says that URL Rewrite is supported on Azure.  Also, the rule can be expressed directly as XML in web.config, as this example shows: codingthis.com/.../wcf-rest-and-url-rewriting-with-windows-azure I looked at a web.config after doing the fix here and it looks as follows: (in <system.webServer>)        <rewrite>            <rules>                <rule name="Rewrite All Requests as UTF-8">                    <match url=".*" />                    <serverVariables>                       <set name="HTTP_ACCEPT_CHARSET" value="utf-8" />                    </serverVariables>                    <action type="Rewrite" url="{UNENCODED_URL}" appendQueryString="false" />                </rule>            </rules>        </rewrite>

• Anonymous
  July 04, 2012
  Thanks Matt, Unfortunately that didn't help me. Here is a link to an screen shot of the error message I am getting... http://ow.ly/i/Kkfe Paul

• Anonymous
  July 04, 2012
  ...further to the above... when I made the update to the web.config file for the LightSwitch application, I got hit with... "500 - Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed." I thought I read that the URL Rewrite modeul was supposed to already be turned on in Azure cloud services. Any ideas? Paul

• Anonymous
  July 06, 2012
  Okay, got it working in Chrome! Amazing what a couple cups of coffee and lots of searching the web can do :)  ...and the answer was staring me right in the face all this time. I added the config settings (as you mentioned above), and then after a couple of hours, realized that I could enable the remote desktop settings to log in and set the URL Rewrite settings in IIS on the web role server. Sheesh! Paul