Re: Cache feature doesn't produce expected result (bug?)

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi Juan,

I want to point out that History mechanisms and caches are different in case you didn't know.
You can read about it in section 13.13 at http://www.faqs.org/rfcs/rfc2616.html
Although I think IE doesn't follow this section ( a cache-control:no-cache does mean a request to the server if you hit back), there could be some semantic differences we have to take into account when talking about the history feature and the browser cache.

1. setting NoCache invalidates SetAllowResponseInBrowserHistory regardless 
of whether SetAllowResponseInBrowserHistory is set to True or False.

I watched the headers going back and forth and SetAllowResponseInBrowserHistory = True only takes away the expires=-1 header if SetCacheability is set to NoCache.
But this has no effect on the browsers behavior. All your tests returned the same result as well as mine. So I think the question is what does expires=-1 try to do and why would you want to get rid of it?

2. If NoCache isn't set but SetAllowResponseInBrowserHistory is set to True
the response is the opposite of what it should be. I would expect SetAllowREsponse
InBrowserHistory to, precisley, allow the browser to use its history cache.

if I Make SetAllowResponseInBrowserHistory True than I _do_ get the page from the cache but this is actually the default behavior of asp.net :
the cache-control header is set to private and the SetAllowResponseInBrowserHistory could as well be commented out. It doesn't add or change any headers on its own.

You get a fresh page?

3. if SetAllowResponseInBrowserHistory is set to False *and*
SetCacheability(HttpCacheability.NoCache) is *not* set
then everything works, sort of, since the result is exactly the opposite
of what I would have expected.

The cached page is displayed right? But this contradicts SetAllowResponseInBrowserHistory=False or its confusing at least.

It seems that the functionality of SetAllowResponseInBrowserHistory works
if set to False instead of being set to True, but only if NoCache isn't set previously.

So you have found a page where setting the SetAllowResponseInBrowserHistory to True or False did influence the outcome??
My test say that SetAllowResponseInBrowserHistory doesn't do anything that's noticeable for the end user
It does however remove the Expires=-1 header when you set SetCacheability to HttpCacheability.NoCache but like I said this doesn't effect a thing in my findings.

I will escalate this up the line to PSS, and try to get a reply. When I 
do, I'll post it back.

Seems I found the right person :) Asking the right question is important. This is what I would ask:

Can you give a code sample where SetAllowResponseInBrowserHistory does have an effect on the end user experience?

Notice that I don't ask what SetAllowResponseInBrowserHistory is supposed to do because after so many tests I don't make any assumption on what it is trying to accomplish.
I hope that with a code sample we can see the effect ourselves and draw conclusions from it. 

Cheers,
Tom Pester


.