Flex + IE + SSL + Domino WQO Agent = Half a Day Wasted
Only bother reading this if you do anything with Flex, Domino and XML. Otherwise it will be a waste of your time.
So, I'd written a Flex app that fetched XML from a Domino-based view, which used a $$ViewTemplate form. This form used a WebQueryOpen agent to add some additional XML to the bottom of the form, alongside the view data itself.
The app worked as a non-SSL version in all browsers and I assumed it was ready for production. However, when I moved it to a live environment which used HTTPS it only worked in non-IE browsers. In IE 7/8 it returned a "HTTP request error".
Looking at the headers of the HTTP request the server returns the right content-length but returned no content. No errors in the Domino log. No nothing. No clues at all.
Opening the URL for the XML directly in IE using SSL worked fine.
If I removed the WQO agent from the $$ViewTemplate form then it worked fine. But as as soon as I put the agent back in there (even just an empty agent would cause it to fail). Although, leaving the agent in doesn't affect any other browser. ODD.
So, why on earth does having a WQO agent cause the server output to die when requested from within Flex if its IE but work if the URL is requested directly or requested from within Flex in any other browser?
Turns out it's because adding a WQO agent causes Domino to add a Pragma:no-cache header and there's a nasty XML-loading bug in IE (Adobe's Technote on it). Looks like it's not a Domino bug after all. Shame on me for assuming it was.
To solve this I added a hidden computed for display field to top of the $$ViewTemplate form called "HTTPHeader" and added the following to it:
@SetHTTPHeader("Cache-control"; "private"); Don't worry though, you can still prevent Flex from using the cached version by adding the following to the code which requests the URL:
httpService.url='vwDashboardAsXML?open&count=-1&_='+new Date().getTime() Part of the beauty of Flex is that you shouldn't need to check a site in any more than one browser before daring to show an IE-using customer. In this case that notion didn't ring true and was a handy reminder that my test environment should always closely mimic the one in which it's going to be used.
Skip to the 
You can subscribe to an individual
I wish I had blogged about this before - could have saved you some time.
I got around the issue by using some website rules to add the headers - I basically made sure that any XML generating design elements started with a title of flex so I could add a wildcard to the rule.
For info I added 2 custom headers - Pragma / Public and Cache-Control / cache, must-revalidate
Reply
You're a nasty, nasty man Mark. Talk about salt in the wound.
Things like this should always be blogged about in the hope they save others the pain. I think of it as developer karma.
Reply
Well thanks for blogging about it, Jake. I have a feeling I'll be "finding" this same issue very soon myself.
I think though the need to add random material to the end of the URL to overcome long standing cache issues with IE has been a known trick for some time... in fact all of my flex urls have something like "&ran=" + Math.random(); at the ends because I had noticed this under other, non SSL, circumstances. But it's a trick I discovered necessary way back when AJAX was coming into vogue. I thought perhaps I learned that from you?
Passive ol' me just always worked around the issue instead of getting at the root. So good on you for the digging.
Reply
Man, it looks like this is ~5 years old, too. If I had to guess MS has no intention of fixing it. Perhaps because Flex competes with Silverlight?
Reply
This is a little off-topic ... but just what does it take to get Domino working with SSL? Do you have to buy an expensive certificate from somebody or can you make your own?
Maybe you can point me at an article that will enlighten me on this subject.
Reply
Hey Rob, ran into this some years back. You can get free / temporary "80%" compatible certificates for development and testing. Or, you can in fact issue your own certificate. IIS actually has a tool for this if you have it running somewhere. You can optionally buy a "high compatibility" certificate from the likes of Verisign. Compatibility is how well browsers will trust the certificate without prompting the user. Generating your own almost guarantees your users will have to answer a one time prompt to trust the certificate.
Reply
Search this site for "SSL". It's been discussed at length.
Reply
IE -- it's the gift that keeps on giving.
Reply
...as a substitute for the Math.random() and new Date() solutions to the urls - try using a if-modified-since http.header with a an outdated date specified.
It will force fresh content from the server (even in IE) and the urls will look much nicer :)
Fredrik
Reply