An interesting thing comes about with RIA applications and deep-links. Say a user arrives at a deep-link:
Note that we're representing the deep-link state in the URL as "Product.aspx?Name=Office+Professional+2007". After the Silverlight XAP loads, any subsequent Silverlight navigation will update the URL fragment as to not refresh the page. So you could easily run into a nasty URL like this:
Now we see two pieces of state in the URL; the (1) original deep-link value in the URL query and the (2) updated application state in the URL fragment. We can't change #1 because that would refresh the page so what do we do?
AsideIt's worth pointing out that everything in the URL before the fragment can be cleaned up by making use of ASP.NET Routing. Similarly, the URL fragment can be cleaned up by making use of Silverlight UriMapping.
The answer depends on how important clean URLs and search engine ranking are to you. (If your app is intranet-only, nix the SEO angle.)
Client-side redirection seems like a great option! So what's the catch? First off, you'll be taking an additional server hit. Second, the user sees a brief flash during redirection. They may even hear the IE "click" sound twice.
These drawbacks are really very minor if a clean URL is important to you. But there is another point to consider: how such redirection behavior appears to search engines. While client-side redirects are fairly common, you need to tread lightly. The reason being that search engines could potentially view such behavior as malicious. If that happens, you risk losing traffic and visibility! If you choose to perform redirects, take precautions and avoiding redirecting across domains and ensure that your redirection URL exists in your down-level markup as well.