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

Discussion in 'ASP .Net' started by Tom.PesterDELETETHISSS@pandora.be, Jun 19, 2005.

  1. Guest

    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 SetAllowResponseInBrowserHistory does.
    While researching caching I tried the code sample at the following page :

    http://msdn2.microsoft.com/library/97wcd0a4(en-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(HttpCacheability.NoCache)
    Response.Cache.SetAllowResponseInBrowserHistory(False) ' False
    is the default
    'Cache-Control: no-cache
    'Expires: -1
    'Pragma: no - Cache

    Response.Cache.SetCacheability(HttpCacheability.NoCache)
    Response.Cache.SetAllowResponseInBrowserHistory(True)
    'Cache-Control: no-cache
    'Pragma: no - Cache


    The docs are right about the Expires header. When SetAllowResponseInBrowserHistory
    = True the Expires header disappears.

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

    Thanks,
    Tom Pester
    , Jun 19, 2005
    #1
    1. Advertising

  2. re:
    > Does anybody have a clue why SetAllowResponseInBrowserHistory was called into existence
    > and where it might be useful?


    SetAllowResponseInBrowserHistory(false) is the default.

    You only need to set HttpCachePolicy.SetAllowResponseInBrowserHistory
    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...
    ======================

    <> wrote in message
    news:...
    > 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
    > SetAllowResponseInBrowserHistory does.
    > While researching caching I tried the code sample at the following page :
    >
    > http://msdn2.microsoft.com/library/97wcd0a4(en-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(HttpCacheability.NoCache)
    > Response.Cache.SetAllowResponseInBrowserHistory(False) ' False is the default
    > 'Cache-Control: no-cache
    > 'Expires: -1
    > 'Pragma: no - Cache
    >
    > Response.Cache.SetCacheability(HttpCacheability.NoCache)
    > Response.Cache.SetAllowResponseInBrowserHistory(True)
    > 'Cache-Control: no-cache
    > 'Pragma: no - Cache
    >
    >
    > The docs are right about the Expires header. When SetAllowResponseInBrowserHistory =
    > True the Expires header disappears.
    >
    > Does anybody have a clue why SetAllowResponseInBrowserHistory was called into existence
    > and where it might be useful?
    >
    > Thanks,
    > Tom Pester
    >
    >
    Juan T. Llibre, Jun 19, 2005
    #2
    1. Advertising

  3. Guest

    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
    , Jun 19, 2005
    #3
  4. 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(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.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.

    Now, if you set
    HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(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
    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...
    ======================

    <> wrote in message
    news:...
    > 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
    >
    >
    Juan T. Llibre, Jun 19, 2005
    #4
  5. Guest

    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...
    > ======================
    > <> wrote in message
    > news:...
    >
    >> 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
    >>
    , Jun 19, 2005
    #5
  6. 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...
    ======================

    <> wrote in message
    news:...
    > 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...
    >> ======================
    >> <> wrote in message
    >> news:...
    >>
    >>> 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
    >>>

    >
    >
    Juan T. Llibre, Jun 19, 2005
    #6
  7. Guest

    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 SetAllowResponseInBrowserHistory 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...
    > ======================
    > <> wrote in message
    > news:...
    >
    >> 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...
    >>> ======================
    >>> <> wrote in message
    >>> news:...
    >>>> 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
    >>>>
    , Jun 19, 2005
    #7
  8. OK...

    First test :
    HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache)
    and
    HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(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.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache)
    was commented out
    HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(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.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache)
    and
    HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(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.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache)
    was commented out
    HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(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.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache)
    is commented out and
    HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(False)
    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...
    ======================

    <> wrote in message
    news:...
    > 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...
    >> ======================
    >> <> wrote in message
    >> news:...
    >>
    >>> 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
    >>>

    >
    >
    Juan T. Llibre, Jun 19, 2005
    #8
  9. Guest

    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
    , Jun 19, 2005
    #9
  10. Guest

    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...
    > ======================
    > <> wrote in message
    > news:...
    >
    >> 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...
    >>> ======================
    >>> <> wrote in message
    >>> news:...
    >>>> 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
    >>>>
    , Jun 20, 2005
    #10
  11. I just verified by commenting out
    SetAllowResponseInBrowserHistory

    btw, what are you using to see the headers ?

    re:
    > Can you report this issue a level higher please?


    Will do so...and post back as soon as I get an answer.




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

    <> wrote in message
    news:...
    > 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...
    >> ======================
    >> <> wrote in message
    >> news:...
    >>
    >>> 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...
    >>>> ======================
    >>>> <> wrote in message
    >>>> news:...
    >>>>> 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
    >>>>>

    >
    >
    Juan T. Llibre, Jun 20, 2005
    #11
  12. Guest

    There are a few excellent freeware/shareware tools that you can use to debug
    :

    - http://www.blunck.info/iehttpheaders.html
    - http://www.fiddlertool.com/fiddler
    - http://www.proxomitron.info

    Some more links :

    - http://www.ieinspector.com/httpanalyzer
    - http://www.iewatch.com
    - http://www.httpsniffer.com/screen.htm
    - http://www.httpwatch.com/viewer.htm

    Firefox has a good extension too.

    Cheers,
    Tom Pester

    > I just verified by commenting out
    > SetAllowResponseInBrowserHistory
    > btw, what are you using to see the headers ?
    >
    > re:
    >
    >> Can you report this issue a level higher please?
    >>

    > Will do so...and post back as soon as I get an answer.
    >
    > Juan T. Llibre
    > ASP.NET MVP
    > http://asp.net.do/foros/
    > Foros de ASP.NET en Español
    > Ven, y hablemos de ASP.NET...
    > ======================
    > <> wrote in message
    > news:...
    >
    >> Hi Juan,
    >>
    >> To come back to your fourth test that differed from the previous
    >> ones:
    >> "Fourth test :
    >> HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.N
    >> oCache) was
    >> commented out
    >> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(F
    >> alse)
    >> 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...
    >>> ======================
    >>> <> wrote in message
    >>> news:...
    >>>> 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.SetAllowResponseInBrowserHistor
    >>>>> y( 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.SetAllowResponseInBrowserHistor
    >>>>> y( 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.SetAllowResponseInBrowserHistor
    >>>>> y( 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.SetAllowResponseInBrowserHistor
    >>>>> y(
    >>>>> 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...
    >>>>> ======================
    >>>>> <> wrote in message
    >>>>> news:...
    >>>>>> 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
    >>>>>>
    , Jun 20, 2005
    #12
  13. Hi, Tom.

    OK, I've been using

    http://www.blunck.info/iehttpheaders.html

    Just wondered which one you're using ( you didn't tell me... )

    ;-)



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

    <> wrote in message
    news:...
    >
    > There are a few excellent freeware/shareware tools that you can use to debug :
    >
    > - http://www.blunck.info/iehttpheaders.html - http://www.fiddlertool.com/fiddler
    > - http://www.proxomitron.info
    >
    > Some more links :
    >
    > - http://www.ieinspector.com/httpanalyzer
    > - http://www.iewatch.com
    > - http://www.httpsniffer.com/screen.htm
    > - http://www.httpwatch.com/viewer.htm
    >
    > Firefox has a good extension too.
    >
    > Cheers,
    > Tom Pester


    >> I just verified by commenting out
    >> SetAllowResponseInBrowserHistory
    >> btw, what are you using to see the headers ?
    >>
    >> re:
    >>
    >>> Can you report this issue a level higher please?
    >>>

    >> Will do so...and post back as soon as I get an answer.
    >>
    >> Juan T. Llibre
    >> ASP.NET MVP
    >> http://asp.net.do/foros/
    >> Foros de ASP.NET en Español
    >> Ven, y hablemos de ASP.NET...
    >> ======================
    >> <> wrote in message
    >> news:...
    >>
    >>> Hi Juan,
    >>>
    >>> To come back to your fourth test that differed from the previous
    >>> ones:
    >>> "Fourth test :
    >>> HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.N
    >>> oCache) was
    >>> commented out
    >>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(F
    >>> alse)
    >>> 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...
    >>>> ======================
    >>>> <> wrote in message
    >>>> news:...
    >>>>> 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.SetAllowResponseInBrowserHistor
    >>>>>> y( 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.SetAllowResponseInBrowserHistor
    >>>>>> y( 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.SetAllowResponseInBrowserHistor
    >>>>>> y( 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.SetAllowResponseInBrowserHistor
    >>>>>> y(
    >>>>>> 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...
    >>>>>> ======================
    >>>>>> <> wrote in message
    >>>>>> news:...
    >>>>>>> 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
    >>>>>>>

    >
    >
    Juan T. Llibre, Jun 20, 2005
    #13
  14. Guest

    Proxomitron cause I use it for other stuff too :)


    Cheers,
    Tom Pester

    > Hi, Tom.
    >
    > OK, I've been using
    >
    > http://www.blunck.info/iehttpheaders.html
    >
    > Just wondered which one you're using ( you didn't tell me... )
    >
    > ;-)
    >
    > Juan T. Llibre
    > ASP.NET MVP
    > http://asp.net.do/foros/
    > Foros de ASP.NET en Español
    > Ven, y hablemos de ASP.NET...
    > ======================
    > <> wrote in message
    > news:...
    >
    >> There are a few excellent freeware/shareware tools that you can use
    >> to debug :
    >>
    >> - http://www.blunck.info/iehttpheaders.html -
    >> http://www.fiddlertool.com/fiddler - http://www.proxomitron.info
    >>
    >> Some more links :
    >>
    >> - http://www.ieinspector.com/httpanalyzer
    >> - http://www.iewatch.com
    >> - http://www.httpsniffer.com/screen.htm
    >> - http://www.httpwatch.com/viewer.htm
    >> Firefox has a good extension too.
    >>
    >> Cheers,
    >> Tom Pester
    >>> I just verified by commenting out
    >>> SetAllowResponseInBrowserHistory
    >>> btw, what are you using to see the headers ?
    >>> re:
    >>>
    >>>> Can you report this issue a level higher please?
    >>>>
    >>> Will do so...and post back as soon as I get an answer.
    >>>
    >>> Juan T. Llibre
    >>> ASP.NET MVP
    >>> http://asp.net.do/foros/
    >>> Foros de ASP.NET en Español
    >>> Ven, y hablemos de ASP.NET...
    >>> ======================
    >>> <> wrote in message
    >>> news:...
    >>>> Hi Juan,
    >>>>
    >>>> To come back to your fourth test that differed from the previous
    >>>> ones:
    >>>> "Fourth test :
    >>>> HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability
    >>>> .N
    >>>> oCache) was
    >>>> commented out
    >>>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory
    >>>> (F
    >>>> alse)
    >>>> 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(HttpCacheabilit
    >>>>> y. No Cache) and
    >>>>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistor
    >>>>> y( 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(HttpCacheabilit
    >>>>> y.
    >>>>> No
    >>>>> Cache)
    >>>>> was commented out
    >>>>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistor
    >>>>> y(
    >>>>> 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(HttpCacheabilit
    >>>>> y. No Cache) and
    >>>>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistor
    >>>>> y( 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(HttpCacheabilit
    >>>>> y. No Cache) was commented out
    >>>>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistor
    >>>>> y( 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(HttpCacheabilit
    >>>>> y.
    >>>>> No
    >>>>> Cache)
    >>>>> is commented out and
    >>>>> HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistor
    >>>>> y(
    >>>>> 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...
    >>>>> ======================
    >>>>> <> wrote in message
    >>>>> news:...
    >>>>>> 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.SetAllowResponseInBrowserHist
    >>>>>>> or y( 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.SetAllowResponseInBrowserHist
    >>>>>>> or y( 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.SetAllowResponseInBrowserHist
    >>>>>>> or y( 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.SetAllowResponseInBrowserHist
    >>>>>>> or
    >>>>>>> y(
    >>>>>>> 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...
    >>>>>>> ======================
    >>>>>>> <> wrote in message
    >>>>>>> news:...
    >>>>>>>> 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
    >>>>>>>>
    , Jun 20, 2005
    #14
  15. Guest

    Hi Juan,

    Any news from the folks at MS?

    Cheers,
    Tom Pester

    > 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 SetAllowResponseInBrowserHistory does.
    > While researching caching I tried the code sample at the following
    > page :
    > http://msdn2.microsoft.com/library/97wcd0a4(en-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(HttpCacheability.NoCache)
    > Response.Cache.SetAllowResponseInBrowserHistory(False) '
    > False
    > is the default
    > 'Cache-Control: no-cache
    > 'Expires: -1
    > 'Pragma: no - Cache
    > Response.Cache.SetCacheability(HttpCacheability.NoCache)
    > Response.Cache.SetAllowResponseInBrowserHistory(True)
    > 'Cache-Control: no-cache
    > 'Pragma: no - Cache
    > The docs are right about the Expires header. When
    > SetAllowResponseInBrowserHistory = True the Expires header disappears.
    >
    > Does anybody have a clue why SetAllowResponseInBrowserHistory was
    > called into existence and where it might be useful?
    >
    > Thanks,
    > Tom Pester
    , Aug 5, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Uenal Mutlu
    Replies:
    1
    Views:
    320
    Victor Bazarov
    Mar 14, 2005
  2. Replies:
    5
    Views:
    462
    Luc The Perverse
    Oct 27, 2006
  3. fizzleBomb
    Replies:
    2
    Views:
    316
    fizzleBomb
    Dec 12, 2006
  4. Vasu
    Replies:
    2
    Views:
    594
    Knute Johnson
    Oct 18, 2008
  5. Michael Tan
    Replies:
    32
    Views:
    966
    Ara.T.Howard
    Jul 21, 2005
Loading...

Share This Page