I found some odd behavior today with respect to the way that Silverlight's HtmlPage.Window.Navigate method works. If a page is cacheable by the client, calling HtmlPage.Window.Navigate will always choose to load the cached version of the page. With IE7, it does this without attempting a cache update check. Normally, IE7 will emit a cache update check for cached content, expecting an HTTP 304 response code, meaning that the cached version is up-to-date. However, when HtmlPage.Window.Navigate references a cached resource, it honors the cached content without checking for an update. This is how Firefox normally behaves and it threw me for a loop as a result. Check out the following code.
// this one will used a cached version always
HtmlPage.Window.Navigate(new Uri("http://server/targetpage.aspx"));
// this one will ignore the cache
HtmlPage.Window.Eval("window.location.href='http://server/targetpage.aspx'");
In that code, the first method call will cause the browser to use a cached page. This is true even if the cache-control was set to private, which is the default. It also does not check for a cache update as IE7 normally does. The second call injects JavaScript into the hosting page for execution. That one seems to force the browser to ignore the cache where the target page was received with the private cache-control policy. I don't know if this is a bug but I know it's not documented that way. I should mention that this happens on Silverlight 2 Beta 1.