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.

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