473,732 Members | 2,207 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

Hi,

I think this question requires an in depth understanding of how a browser
cache works. I hope I can reach an expert here.

I may have found a quirk in the asp.net documentation or I don't understand
what the SetAllowRespons eInBrowserHisto ry does.
While researching caching I tried the code sample at the following page :

http://msdn2.microsoft.com/library/9...us,vs.80).aspx

I find this code absurd since it tries to show that you can view a page that
has been _posted_ with the history feature of the browser.

Can you try this code and report your findings please? I tried it on a clean
VM install and on my dev pc: the browser says "page expired".
The docs say you would see the old page in the browser.

I did some tests and this is what the following code does with the response
headers :

Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(False) ' False
is the default
'Cache-Control: no-cache
'Expires: -1
'Pragma: no - Cache

Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(True)
'Cache-Control: no-cache
'Pragma: no - Cache
The docs are right about the Expires header. When SetAllowRespons eInBrowserHisto ry
= True the Expires header disappears.

Does anybody have a clue why SetAllowRespons eInBrowserHisto ry was called
into existence and where it might be useful?

Thanks,
Tom Pester
Nov 19 '05 #1
14 2091
re:
Does anybody have a clue why SetAllowRespons eInBrowserHisto ry was called into existence
and where it might be useful?
SetAllowRespons eInBrowserHisto ry(false) is the default.

You only need to set HttpCachePolicy .SetAllowRespon seInBrowserHist ory
when you need to set it to true to override the NoCache setting


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com... Hi,

I think this question requires an in depth understanding of how a browser cache works. I
hope I can reach an expert here.

I may have found a quirk in the asp.net documentation or I don't understand what the
SetAllowRespons eInBrowserHisto ry does.
While researching caching I tried the code sample at the following page :

http://msdn2.microsoft.com/library/9...us,vs.80).aspx

I find this code absurd since it tries to show that you can view a page that has been
_posted_ with the history feature of the browser.

Can you try this code and report your findings please? I tried it on a clean VM install
and on my dev pc: the browser says "page expired".
The docs say you would see the old page in the browser.

I did some tests and this is what the following code does with the response headers :

Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(False) ' False is the default
'Cache-Control: no-cache
'Expires: -1
'Pragma: no - Cache

Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(True)
'Cache-Control: no-cache
'Pragma: no - Cache
The docs are right about the Expires header. When SetAllowRespons eInBrowserHisto ry =
True the Expires header disappears.

Does anybody have a clue why SetAllowRespons eInBrowserHisto ry was called into existence
and where it might be useful?

Thanks,
Tom Pester

Nov 19 '05 #2
Hi Juan,

Thanks for your response.
You only need to set HttpCachePolicy .SetAllowRespon seInBrowserHist ory
when you need to set it to true to override the NoCache setting


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

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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
Nov 19 '05 #3
re:
You only need to set HttpCachePolicy .SetAllowRespon seInBrowserHist ory
when you need to set it to true to override the NoCache setting
Setting SetAllowRespons eInBrowserHisto ry 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 HttpCacheabilit y is set to NoCache or ServerAndNoCach e
the Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCach e 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 SetAllowRespons eInBrowserHisto ry is set to True,
the Expires HTTP header is removed.

If you comment out this line :
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(True)
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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(False)
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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(True)
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
SetAllowRespons eInBrowserHisto ry 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...
=============== =======

<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com... Hi Juan,

Thanks for your response.
You only need to set HttpCachePolicy .SetAllowRespon seInBrowserHist ory
when you need to set it to true to override the NoCache setting


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

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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

Nov 19 '05 #4
Hi Juan,

I tried exactly the steps that you advised but this is where I can't reproduce
If you set HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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 SetAllowRespons eInBrowserHisto ry
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 SetAllowRespons eInBrowserHisto ry to true or false... I never see
a difference.

Cheers,
Tom Pester

re:
You only need to set
HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
set it to true to override the NoCache setting

Setting SetAllowRespons eInBrowserHisto ry 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 HttpCacheabilit y is set to NoCache or ServerAndNoCach e the
Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCach e 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 SetAllowRespons eInBrowserHisto ry is set to True, the Expires HTTP
header is removed.

If you comment out this line :
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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
SetAllowRespons eInBrowserHisto ry 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...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

Thanks for your response.
You only need to set
HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
set it to true to override the NoCache setting

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

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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

Nov 19 '05 #5
re:
Could it be that you saw this when testing without restarting IE?
I didn't restart IE, thinking that editing the source file would
automatically force recompilation ( and return a new page anyway ).

Let me take a look at it while closing IE, and I'll post back.


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======

<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com... Hi Juan,

I tried exactly the steps that you advised but this is where I can't reproduce
If you set HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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
SetAllowRespons eInBrowserHisto ry 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 SetAllowRespons eInBrowserHisto ry to true or false... I never see a difference.

Cheers,
Tom Pester

re:
You only need to set
HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
set it to true to override the NoCache setting

Setting SetAllowRespons eInBrowserHisto ry 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 HttpCacheabilit y is set to NoCache or ServerAndNoCach e the
Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCach e 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 SetAllowRespons eInBrowserHisto ry is set to True, the Expires HTTP
header is removed.

If you comment out this line :
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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
SetAllowRespons eInBrowserHisto ry 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...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

Thanks for your response.

You only need to set
HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
set it to true to override the NoCache setting

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

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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


Nov 19 '05 #6
Thx for sticking with this Juan. I dont have an urgent problem with this
feature, I just whant to know everyting there is about caching cause I neglected
it for too long.
This SetAllowRespons eInBrowserHisto ry is one of the last mysteries for me.

Thanks,
Tom Pester

PS I am using ASP.NET V2 Beta 2 so the page recompiles every time I make
a change.

re:
Could it be that you saw this when testing without restarting IE?

I didn't restart IE, thinking that editing the source file would
automatically force recompilation ( and return a new page anyway ).

Let me take a look at it while closing IE, and I'll post back.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

I tried exactly the steps that you advised but this is where I can't
reproduce
If you set
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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
SetAllowRespons eInBrowserHisto ry 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 SetAllowRespons eInBrowserHisto ry to true or false... I never
see a difference.

Cheers,
Tom Pester
re:

> You only need to set
> HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
> set it to true to override the NoCache setting
>
Setting SetAllowRespons eInBrowserHisto ry 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 HttpCacheabilit y is set to NoCache or ServerAndNoCach e the
Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCach e 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 SetAllowRespons eInBrowserHisto ry is set to True, the Expires
HTTP header is removed.

If you comment out this line :
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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
SetAllowRespons eInBrowserHisto ry 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...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

Thanks for your response.

> You only need to set
> HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
> set it to true to override the NoCache setting
>
Setting SetAllowRespons eInBrowserHisto ry to True doesn't
touch/override the "no-cache" value. It only removes the expires=-1
header.

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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

Nov 19 '05 #7
OK...

First test :
HttpContext.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.NoCache )
and
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(True)

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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.NoCache )
was commented out
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(True)
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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.NoCache )
and
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(False)

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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.NoCache )
was commented out
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(False)
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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.NoCache )
is commented out and
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(False)
is left in the code.

My conclusions :

1. setting NoCache invalidates SetAllowRespons eInBrowserHisto ry
regardless of whether SetAllowRespons eInBrowserHisto ry is set to True or False.

2. If NoCache isn't set but SetAllowRespons eInBrowserHisto ry is set to True
the response is the opposite of what it should be. I would expect SetAllowREspons e
InBrowserHistor y to, precisley, allow the browser to use its history cache.

3. if SetAllowRespons eInBrowserHisto ry is set to False *and*
SetCacheability (HttpCacheabili ty.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 SetAllowRespons eInBrowserHisto ry
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...
=============== =======

<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

I tried exactly the steps that you advised but this is where I can't reproduce
If you set HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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
SetAllowRespons eInBrowserHisto ry 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 SetAllowRespons eInBrowserHisto ry to true or false... I never see a difference.

Cheers,
Tom Pester

re:
You only need to set
HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
set it to true to override the NoCache setting

Setting SetAllowRespons eInBrowserHisto ry 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 HttpCacheabilit y is set to NoCache or ServerAndNoCach e the
Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCach e 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 SetAllowRespons eInBrowserHisto ry is set to True, the Expires HTTP
header is removed.

If you comment out this line :
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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
SetAllowRespons eInBrowserHisto ry 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...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

Thanks for your response.

You only need to set
HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
set it to true to override the NoCache setting

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

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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


Nov 19 '05 #8
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 SetAllowRespons eInBrowserHisto ry regardless of whether SetAllowRespons eInBrowserHisto ry is set to True or False.

I watched the headers going back and forth and SetAllowRespons eInBrowserHisto ry
= 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 SetAllowRespons eInBrowserHisto ry is set to True
the response is the opposite of what it should be. I would expect SetAllowREspons e
InBrowserHisto ry to, precisley, allow the browser to use its history cache.
if I Make SetAllowRespons eInBrowserHisto ry 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 SetAllowRespons eInBrowserHisto ry
could as well be commented out. It doesn't add or change any headers on its
own.

You get a fresh page?
3. if SetAllowRespons eInBrowserHisto ry is set to False *and*
SetCacheabilit y(HttpCacheabil ity.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 SetAllowRespons eInBrowserHisto ry=False
or its confusing at least.
It seems that the functionality of SetAllowRespons eInBrowserHisto ry 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 SetAllowRespons eInBrowserHisto ry
to True or False did influence the outcome??
My test say that SetAllowRespons eInBrowserHisto ry doesn't do anything that's
noticeable for the end user
It does however remove the Expires=-1 header when you set SetCacheability
to HttpCacheabilit y.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 SetAllowRespons eInBrowserHisto ry does have
an effect on the end user experience?

Notice that I don't ask what SetAllowRespons eInBrowserHisto ry 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
Nov 19 '05 #9
Hi Juan,

To come back to your fourth test that differed from the previous ones:
"Fourth test : HttpContext.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.NoCache )
was commented out HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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 SetAllowRespons eInBrowserHisto ry 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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.No
Cache) and
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.No
Cache)
was commented out
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.No
Cache) and
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.No
Cache) was commented out
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(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.Cur rent.Response.C ache.SetCacheab ility(HttpCache ability.No
Cache)
is commented out and
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(Fa
lse)
is left in the code.
My conclusions :

1. setting NoCache invalidates SetAllowRespons eInBrowserHisto ry
regardless of whether SetAllowRespons eInBrowserHisto ry is set to True
or False.

2. If NoCache isn't set but SetAllowRespons eInBrowserHisto ry is set to
True
the response is the opposite of what it should be. I would expect
SetAllowREspons e
InBrowserHistor y to, precisley, allow the browser to use its history
cache.
3. if SetAllowRespons eInBrowserHisto ry is set to False *and*
SetCacheability (HttpCacheabili ty.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 SetAllowRespons eInBrowserHisto ry
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...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

I tried exactly the steps that you advised but this is where I can't
reproduce
If you set
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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
SetAllowRespons eInBrowserHisto ry 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 SetAllowRespons eInBrowserHisto ry to true or false... I never
see a difference.

Cheers,
Tom Pester
re:

> You only need to set
> HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
> set it to true to override the NoCache setting
>
Setting SetAllowRespons eInBrowserHisto ry 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 HttpCacheabilit y is set to NoCache or ServerAndNoCach e the
Expires HTTP header is set to -1 by default.

NoCache and ServerAndNoCach e 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 SetAllowRespons eInBrowserHisto ry is set to True, the Expires
HTTP header is removed.

If you comment out this line :
HttpContext.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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.Cur rent.Response.C ache.SetAllowRe sponseInBrowser History(
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
SetAllowRespons eInBrowserHisto ry 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...
=============== =======
<To************ ********@pandor a.be> wrote in message
news:a1******** *************** ***@news.micros oft.com...
Hi Juan,

Thanks for your response.

> You only need to set
> HttpCachePolicy .SetAllowRespon seInBrowserHist ory when you need to
> set it to true to override the NoCache setting
>
Setting SetAllowRespons eInBrowserHisto ry to True doesn't
touch/override the "no-cache" value. It only removes the expires=-1
header.

This code shows this :
Response.Cache. SetCacheability (HttpCacheabili ty.NoCache)
Response.Cache. SetAllowRespons eInBrowserHisto ry(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/9...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

Nov 19 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

15
2130
by: Jordan Rastrick | last post by:
First, a disclaimer. I am a second year Maths and Computer Science undergraduate, and this is my first time ever on Usenet (I guess I'm part of the http generation). On top of that, I have been using Python for a grand total of about a fortnight now. Hence, I apologise if what follows is a stupid suggestion, or if its already been made somewhere else, or if this is not the appropriate place to make it, etc. But I did honestly do some...
1
1228
by: Uenal Mutlu | last post by:
If "extern" is specified for a variable which is already in the same cpp file then the compiler (VS6) creates a new instance of the var in each thread. Is this a bug or a feature? Which is standard conform? Example: test.cpp: int gi = 0;
9
2146
by: Just D. | last post by:
All, Did anybody see this strange effect? The web application is written in C#, ASP.NET, SQL, T-SQL, etc. A pretty usual stuff, complicated enough, but works fine until... Here is a question. I don't see any problem if I start this app on my local computer against my local IE both in debug or release modes. If I upload the same app to my corporate server where it works under HTTPS here are a few possible ways.
30
3306
by: Raymond Hettinger | last post by:
Proposal -------- I am gathering data to evaluate a request for an alternate version of itertools.izip() with a None fill-in feature like that for the built-in map() function: >>> map(None, 'abc', '12345') # demonstrate map's None fill-in feature The motivation is to provide a means for looping over all data elements
5
2118
by: Stan SR | last post by:
Hi, Some newbie questions.. :-) First, what is the namespace to use for the Cache class ? When I use this bit of code I get an error if (Cache==null) Cache.Insert("myUserList",userlist); I don't know which namespace to use.
4
2738
by: RedHair | last post by:
Development: Windows 2003 Production :Windows 2003 ASP.NET 2.0 + C# I want to disable the cache feature of all pages in dev but enable it in production environments. What's the solution? If uses cacheProfiles in web.config then I need to deploy different web.config files from dev to production sites.
3
1848
by: Dave | last post by:
Using ASP.Net 2.0 on Vista with IIS6, if I set a CacheDependency on a file into a Cache entry that I insert and then delete a subdirectory in the same directory that the file is located in then my dependency is triggered and my cache object is deleted. If I create a directory or delete another file in that same directory then the Cache is not bothered. My CacheDependency specifies the full and proper file name and not just the...
7
2013
by: Andrew Jocelyn | last post by:
Hi I'm running an ASP.NET web application under IIS. I'm inserting a cache object with a file based CacheDependency. I've noticed that when the file changes the Cache object is not always immediately invalidated. e.g. Cache.Insert("myobj", data, new CacheDependency(filePath)); When I make a change to the file 'filePath' and call the object from the cache it is not null. I'm disposing of the FileStream object immediately
0
8946
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9307
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
9235
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9181
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
6735
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4550
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4809
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2721
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2180
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.