Silverlight and IE Web Services Bug

UPDATE 2 — the workaround:

Using SSL with Silverlight and IE is tricky.  The Microsoft team is too busy to look hard at anything until after MIX (by the way very excited for Silverlight 3 guys!).  They don’t share public information about bugs like this which is understandable due to security concerns.  So I have my own solution, unfortunately without understanding root cause, but it works.

If you are calling web services over SSL from your silverlight app you will experience issues in IE6 and IE7.  Cache settings interact with the user’s own settings to prevent silverlight from receiving responses in many common configurations.  To prevent this completely in IE7 use “cache-control: private” in your response headers.

IE6 for some reason still throws an exception with this header, if the page is also https.  If the page, however, is http and the web services are still https, everything works.  I really cannot explain this but it works for now, and all the sensitive data is going over the web services layer.

My final solution:

  1. Send cache-control: private in the headers for all responses.
  2. Sniff for IE6 on the server side (this was a last resort) and redirect the page to http instead of https.
  3. Disable compression on the server to avoid the gzip bugs relating to IE which are discussed in the post below and originally kicked off these IE-Silverlight issues.

My only concern was using cache-control:private instead of preventing caching altogether for sensitive data.  Looking at IE’s local cache, it doesn’t seem to cache any of these responses to soap requests anyway, and the header prevents any storage in public or shared caches.

If this solution continues to hold up, I can wait for the real fix to arrive in Silverlight 3, which the team assures me is going to happen.

UPDATE (read below for original problem background):

After a lot more testing and digging, I’ve pinpointed this problem to an interaction with SSL.
In IE, you can go to Tools / Options / Advanced and check “Do not save encrypted files to disk”.  This clears up the problem for me.  From reading online, it seems that preventing caching with this option unchecked leads to a bug where IE does not save the file to disk due to the cache restrictions, but then cannot load the file because it expects it be on disk. Checking this apparently causes everything to happen in memory.  Many thanks to the forum post at  http://silverlight.net/forums/t/55653.aspx for this tip.
Asking users to check this box is a big problem, however.  I saw one suggestion online about setting cache-control to private instead of none.  However, the original workaround to the gzip/caching bug required that we prevent caching. This leaves me in a pickle with probably no choice but to prevent gzip on all responses which is a bummer with large XML responses coming out of WCF, and also harder to control than you might think via a web host.
In summary, I think there are 2 IE bugs in play:
1. gzipped and cached responses cannot be read by IE
2. SSL responses with “Do not save encrypted files to disk” unchecked and no caching
These both looks very similar.  I still cannot understand why #2 started happening on multiple computers all of a sudden when no changes were made to the application.  No changes were made to the computers either except via windows update.
I’m not sure why Microsoft has not shared an official line on this bug (bugs?) including exactly what the problem is, what the workarounds are, etc.  The forum thread does not count.  There are bug reports on adobe.com about similar issues with IE and Flash.  I’ve tried very hard to give them information (and to get it from them) to no avail other than “we know about it and will fix it in SL 3.”  I’m not sure what they know about because they won’t confirm the exact nature of the bugs they believe are being reported on a random forum thread.  These problems are a huge silverlight limitation and are causing me to wonder if I made the right choice in Silverlight for this project.

———————————————————————

Silverlight has a serious problem.  I’m surprised we don’t hear more about this problem, and the fact that we don’t makes me worry that there aren’t that many developers actually deploying real silverlight apps that use web services.

Fiddler's view of a perfectly good HTTP response that Silverlight cannot handle.

Fiddler's view of a perfectly good HTTP response that Silverlight cannot handle.

Click to view the above image at full size.

There is a known bug that you can read all about on this forum thread:  http://silverlight.net/forums/p/42908/185818.aspx#185818

The forum describes a problem, initially with IE6, where Silverlight 2 RTW cannot accept responses that are both gzipped and cached.  The solution?  Prevent caching.  This took weeks of difficult debugging and searching to figure out.  The workaround:  add pragma:no-cache and expires:-1 to all responses going back to silverlight and it works.  This affected my users on IE6 and IE7, and I’ve now confirmed it with IE8 too.  But the workaround was working, until this week.

On three separate computers, all of which have recently take the Silverlight update of 2/26/2009, as well as standard windows updates, this bug is now resurfacing.  No changes whatsoever have been made to the silverlight xap or to the WCF services — nothing on that server has changed.  Yet here we are again, and this time our known workaround is not working.

I worked for a couple hours with the good people at Mosso to see if any changes they have recently made could have affected me and I’m convinced that they have not.

To be clear for anyone that might have a similar problem or a solution:  Using IE7, Silverlight 2 RTW, and an SSL connection, I cannot receive responses from a WCF service.  I get this helpful error message:

System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid. Check InnerException for exception details. —> System.ServiceModel.CommunicationException: The remote server returned an error: NotFound —> System.Net.WebException: The remote server returned an error: NotFound —> System.Net.WebException: The remote server returned an error: NotFound

at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
at System.Net.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)
— End of inner exception stack trace —
at System.Net.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
— End of inner exception stack trace —
at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
at WebStaging.Register.UserServiceClient.UserServiceClientChannel.EndGetReportDirectoryXML(IAsyncResult result)
at WebStaging.Register.UserServiceClient.Register_UserService_EndGetReportDirectoryXML(IAsyncResult result)
at WebStaging.Register.UserServiceClient.OnEndGetReportDirectoryXML(IAsyncResult result)
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)
— End of inner exception stack trace —
at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionI…

Of course, this works fine in FireFox, Chrome, etc.  The problem is very specific to IE.  It’s a known problem that Microsoft says they are addressing in Silverlight 3.  But something has happened, most likely with the recent Silverlight service update, to make this problem worse such that the known workaround no longer works.

In the screenshot above, you can see a perfectly valid request and response going over SOAP.  The service returns a single argument (XML document as a string).  Fiddler managed to decode the response no problem without applying any decompression, but Silverlight throws the error.

This problem plagued us for weeks until we figured it out and had to take the undesirable route of turning off all caching.  Now it’s haunting us again and at the moment all IE users to my site will see this error.   If anyone at Microsoft reads this, please help us out.

–Pete

About these ads

11 responses to “Silverlight and IE Web Services Bug

  • brother

    Same problem here. thanks for good post.

  • Marten

    I’m getting the same issue – SL2/IE/HTTPS.

    It was working for us for a while and then all of a sudden it stopped. I too have an upset customer.

    I’ve got a thread going on this (referencing yours) on Silverlight.net/forums:

    http://silverlight.net/forums/p/87700/204665.aspx

  • Marten

    BTW – this problem goes away when I try IE & SL3 client beta.

  • otoole

    Hi Marten —

    Glad to know I’m not insane. I can’t believe how few people must be using IE with Silverlight and SSL. I’m glad to hear that this is working in SL3. I really want to move to SL3 but not until there is a go-live license. I’ve been working with silverlight through the first betas and I need to ship on a stable platform for now.

    Try the tips in my post — cache-control:private worked for me, which was strange because originally cache-control:no-cache was the recommended solution! I think Microsoft did make some changes in the SL2 update in February… though they deny it. No other reason this behavior would have suddenly changed.

  • Marten

    No success for me.

    I tried the settings in http://support.microsoft.com/kb/234067 as well, but still not working:

    cache-control: no-cache, pragma: no-cache; expires: -1

    Also tried changing to private with the other 2 settings to no avail.

  • otoole

    For some reason, using http for the page and https for the web service fixes the problem in IE6. You might try that — this is one of those problems where you just start trying anything and everything, unfortunately, because we don’t know the root cause.

  • Marten

    I get a security error. I only have a crossdomain.xml setup and it’s contents are:

    Unforuntately I can’t host a http on the same host as my https.

    So the https backend is https://my.volorecovery.com and the http serving up the page is http://www.volorecovery.com.

  • Marten

    I’ve got it working for me:

    In my PHP code:
    header(“Cache-Control: private”);
    header(“Pragma: public”);
    header(“Expires: 0″);

  • mike

    I have spoke to Microsoft about this issue. They told me there is no solution and there is no work-around. The problem is with IE…

    The only solution is SL3… can’t believe it.

  • james

    I’ve had a similar issue, using Data Services and Silverlight (which is of course a WCF service). The distribution is as you describe, IE6 mostly, but not all IE6 users. However in terms of Data Services it is only affecting calls where data is updated. Reads all work fine for some reason. The effect is that the browser hangs – I suspect it is going nuts trying to process this exception. Has anyone seen this and got any ideas of work arounds?

  • otoole

    It sounds like a different bug because I usually get a quick exception instead of hanging. But who knows? I have not used data services… Check out the responses from write vs. read requests to see if they are gzipped and how they are cached to see how it compares to what I found above.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: