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.


    • avatar
    • Mark Barton
    • Fri 16 Apr 2010 07:14 AM

    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

      • avatar
      • Jake Howlett
      • Fri 16 Apr 2010 07:34 AM

      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.

  1. 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.

    • avatar
    • Erik Brooks
    • Fri 16 Apr 2010 11:24 AM

    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?

  2. 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.

    1. 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.

      • avatar
      • Jake Howlett
      • Mon 19 Apr 2010 09:21 AM

      Search this site for "SSL". It's been discussed at length.

  3. IE -- it's the gift that keeps on giving.

  4. ...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 :)


Your Comments


About This Page

Written by Jake Howlett on Fri 16 Apr 2010

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content