By daveatwork on Apr 01, 2009
As you know by reading earlier posts on this blog, we have been working on improving the performance of our Web UI. The authentication user interaction is tightly integrated with rest of the Web UI to provide seamless experience in the rich Web UI. Combining this with the requirement to encrypt user names and passwords, we initially run the entire application under SSL. Ideally, we'd figure out a way to use SSL only for the parts of the communication that require encryption, and regular HTTP traffic for all
other aspects of our application (e.g. search results, images, etc.)
We are experimenting with a new feature that enables the web UI to interact with both SSL based web services and non-SSL based web services within the same browser page. This is one optimization that can help the web site to better scale with increasing traffic.
One technique is the use of iframes with fragment identifiers (text after the hash character in an URL, i.e. http://domain.com/page.html#tragment_identifier). This combination enables the web UI to establish a communication channel needed to pass small amount of information needed between iframes to interact with both SSL and non-SSL service points. For further explanation and a working example, please see this blog post for more information.
This use of fragment identifiers as a cross-domain communication channel is in direct overlap with popular practices for history management, which also use fragment identifiers to store page rendering state. Here is a sample page that shows how this feature works.
This leaves us with a potential situation when a page's rendering state can be wiped out whenever iframes use the same fragment identifiers to pass messages among them. In our particular use case, this is not a problem when the message actually leads to a new page state. If this is not the case, then it may lead to an inconsistent state between the representation in the URL and what's displayed on the page. One work around is to reset or synchronize the page state for such scenarios, which is a minor de-optimization that can generate repeat AJAX calls. This will be an interesting challenge to integrate conflicting features. Look for this performance improvement in an upcoming release