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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Juan,

To come back to your fourth test that differed from the previous ones:
"Fourth test : HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache) was commented out HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(False) was left in code."

If you dont use SetCacheability on a page than ASP switches back to its default cache-control wich is private, ie the browser may cache the page. So you can press the submit button many times and still go back in history.
Setting SetAllowResponseInBrowserHistory to False of True has no effect at all on the headers so it could as well be commented out.

Can you report this issue a level higher please?

Let me know if you have any more questions..

Cheers,
Tom Pester

OK...

First test :
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.No
Cache) and
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(Tr
ue)

Results :
Browser doesn't produce "Page has expired" message
unless the submit button is clicked more than once.
Browser does produce "Page has expired" message
if the submit button is clicked more than once.
Single-click behavior returns different time stamps for each page.

Browser closed.

Second test :
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.No
Cache)
was commented out
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(Tr
ue)
is left in code
Results :
Browser doesn't produce "Page has expired" message
unless the submit button is clicked more than once.
Browser does produce "Page has expired" message
if the submit button is clicked more than once.
Single-click behavior returns different time stamps for each page.

( same results as the first test )

Browser closed.

Third test :
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.No
Cache) and
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(Fa
lse)

Results :
Browser doesn't produce "Page has expired" message
unless the submit button is clicked more than once.
Browser does produce "Page has expired" message
if the submit button is clicked more than once.
Single-click behavior returns different time stamps for each page.

( same results as the first and second tests )

Browser closed.

Fourth test :
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.No
Cache) was commented out
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(Fa
lse) was left in code.

Results :
Browser doesn't produce "Page has expired" message at any time.
Browser allows returning to previous versions of page ( as determined
by the date stamp ) no matter how many times the submit button is
pressed successively.

Whew !

Analysis :
The only time the code works as expected is when
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.No
Cache)
is commented out and
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(Fa
lse)
is left in the code.
My conclusions :

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

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

This is very strange, but I've seen stranger.

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

Before doing that, I'll wait for any last comments you might have.
Thanks for pointing this out.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================
<Tom.PesterDELETETHISSS@xxxxxxxxxx> wrote in message
news:a1a977a22ed738c742f45e90c666@xxxxxxxxxxxxxxxxxxxxx

Hi Juan,

I tried exactly the steps that you advised but this is where I can't
reproduce

If you set
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(
False)

you'll see that immediately the "This page has expired" message *is*
displayed, and the client needs to resubmit the >page.

I dont see the "This page has expired" message and if I comment out
SetAllowResponseInBrowserHistory I get the same result as False is
the default. No "This page has expired" message, the browser request
a new page as I can see by the time.

Could it be that you saw this when testing without restarting IE? I
even made a video of my clean virtual machine (just SP2 installed) to
show you my result.

Please try this:
http://users.pandora.be/TomPester/ASP/r.rar
Do you realy get a "This page has expired" when you do what's on the
video? I don't.

Setting SetAllowResponseInBrowserHistory to true or false... I never
see a difference.

Cheers,
Tom Pester

re:

You only need to set
HttpCachePolicy.SetAllowResponseInBrowserHistory when you need to
set it to true to override the NoCache setting

Setting SetAllowResponseInBrowserHistory to True doesn't
touch/override the "no-cache" value. It only removes the expires=-1
header.

Maybe we have a semantics problem here.

Removing the expires= -1 header *equals* overriding the "NoCache"
value.

When HttpCacheability is set to NoCache or ServerAndNoCache the
Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCache instruct the client to not cache
responses in the History folder by setting that header.

This means that each time you use the back/forward buttons, the
client requests a new version of the response.

When SetAllowResponseInBrowserHistory is set to True, the Expires
HTTP header is removed.

If you comment out this line :
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(
Tr ue) and alternate between clicking the Submit button and the Back
button, you'll see that the "This page has expired" message is not
displayed.

That means that the client *has* requested a new version of the
page, without having to resubmit the page.

If you set
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(
Fa lse) you'll see that immediately the "This page has expired"
message *is* displayed, and the client needs to resubmit the page.

Now, if you set
HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(
Tr
ue)
and alternate between the Submit button and the Back button,
you'll see that the "This page has expired" message is not
displayed,
and the page is displayed without needing to resubmit the page.
The documentation is wrong in requesting that you
"Click the Submit button a few times".
That throws a wrench into the works.
You should only hit it once to see the correct behavior.
The documentation is also wrong when it states that
SetAllowResponseInBrowserHistory allows client-side caching.
In effect all it does is remove the need to resubmit the page.

I hope this makes this issue clearer.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================
<Tom.PesterDELETETHISSS@xxxxxxxxxx> wrote in message
news:a1a977a22e56e8c742966a1df0de@xxxxxxxxxxxxxxxxxxxxx

Hi Juan,

Thanks for your response.

You only need to set
HttpCachePolicy.SetAllowResponseInBrowserHistory when you need to
set it to true to override the NoCache setting

Setting SetAllowResponseInBrowserHistory to True doesn't
touch/override the "no-cache" value. It only removes the expires=-1
header.

This code shows this :
Response.Cache.SetCacheability(HttpCacheability.NoCache)
Response.Cache.SetAllowResponseInBrowserHistory(True)

The servers send the following cache related headers :
'Cache-Control: no-cache
'Pragma: no - Cache
I don't know if you are experienced in http headers and their
behavior but could you please test the code that's on this page and
report your result? :
http://msdn2.microsoft.com/library/97wcd0a4(en-us,vs.80).aspx

If you run the sample and go back with your browser I think you
will find that the text on the page is wrong.

Thanks in advance, Tom



.

Relevant Pages

  • Re: Cache feature doesnt produce expected result (bug?)
    ... Browser doesn't produce "Page has expired" message ... regardless of whether SetAllowResponseInBrowserHistory is set to True or False. ... >> Expires HTTP header is set to -1 by default. ... >> When SetAllowResponseInBrowserHistory is set to True, the Expires HTTP ...
    (microsoft.public.dotnet.framework.aspnet)
  • Loadrunner and http expires header
    ... We are configuring our Apache web server to send "Expires" header with ... gif images so that browser can cache them for few days. ... can see any improvement in hits/sec or response time with expires ... Does anyone know if the browser simulated by loadrunner honors the ...
    (comp.software.testing)
  • Re: Cache feature doesnt produce expected result (bug?)
    ... Thx for sticking with this Juan. ... SetAllowResponseInBrowserHistory I get the same result as False is the default. ... responses in the History folder by setting that header. ... When SetAllowResponseInBrowserHistory is set to True, the Expires ...
    (microsoft.public.dotnet.framework.aspnet)
  • (not) caching with mod_expires
    ... trying to get our content to cache nicely at the browser. ... URL causes a conditional request and a 304 response. ... Expires: Wed, ...
    (comp.infosystems.www.servers.unix)
  • Re: Is ISA 2004s caching busted ?
    ... It sounds like that's what's happening although the files from Microsoft ... I wonder if it just erases them from the cache afterwards ... expires in the cache almost as soon as it's being commited to the disk ...
    (microsoft.public.isa)