I still can’t get used to the immature text editing experience embedded in web browsers, even editors that push the limit like Google Docs. Windows Live Writer claims to give you the desktop experience with full fidelity preview of how it will look on a blog. Let’s give this a try!
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:
- Send cache-control: private in the headers for all responses.
- Sniff for IE6 on the server side (this was a last resort) and redirect the page to http instead of https.
- 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):
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.
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 —
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.
In one of his usual insightful pieces on lab software, Bruce Friedman writes about the oops button present in some major anatomic pathology (AP) systems. The feature provides a grace period after a pathology report is signed out before it is released for consumption by the referring physician. Friedman notes how this is not appropriate for clinical lab systems, which deal mainly in numbers, as opposed to AP systems, which deal mainly with narrative text:
Most clinical pathology results are numerical and various rules can be deployed such as autoverification or interval checking to catch errors… By way of contrast, the surgical pathologist frequently works alone, creating narrative reports not amenable to rule-checking or real-time quality control.
I would like to add that the shift toward structured, synoptic AP reports changes this. Unfortunately, most synoptic reporting modules inside traditional AP systems do little more than produce bullet-like text. A very few systems, including mTuitive’s xPert for Pathology, provide true structured, synoptic reporting. What’s the difference? A synoptic report presents discrete data points to the human eye, while a structured report is stored as discrete data and enables all the benefits of granular data — querying, analysis, quality control using database technologies, expert systems, and so forth.
Pathologists are some of the most patient, meticulous, and knowledgable people in the world. The density of information in a typical pathology report on a malignant tumor far outweighs most written communication in medicine or elsewhere. It is time for AP data to become first-class citizens in the modern world of data management. The way to do this is not to turn pathologists into data entry clerks, but to give them tools that enhance their already instant recall of voluminous knowledge, that give them a consistent method of communicating life-and-death factors to surgeons and oncologists, that help keep the generalists up to date with the specialists, that do allow rule-checking and sophisticated algorithms to prevent errors and find rare diagnoses, that via aggregation of structured data enable real-time epidemiology. The people and the job remain the same, but oh what you can do with the results! Synoptic reporting changes everything.