CACHE, BUFFER, system bug or what?

[Just D.]

All,

Did anybody see this strange effect? The web application is written in C#,
ASP.NET, SQL, T-SQL, etc. A pretty usual stuff, complicated enough, but
works fine until...

Here is a question. I don't see any problem if I start this app on my local
computer against my local IE both in debug or release modes. If I upload the
same app to my corporate server where it works under HTTPS here are a few
possible ways.

1. It works just great if the Advanced Internet option "Do not save
encrypted pages to disk" is checked on.
2. If I uncheck this option then it still works if I run it on my local IIS
against my local IE,
3. ... but if I run this app against my corporate server with my local IE
then here is a very interesting bug. I'm able to login as one client using
his login/password, then I can click the Backspace button, get the login
page again, enter another login/password, then click OK and get the page
belonging to the first patient like it was already stored in some buffer and
returned back to me. All pages and the whole app are configured to ignore
the cache, all aspx pages are having this tag:

<meta http-equiv="CACHE-CONTROL" content="NO-CACHE">

No results at all! What's going on? Is the operating system too stupid to
cache pages inside one session and ignore all settings made right in the
program code? It doesn't happen if I call new pages one by one, the app is
written so that it generates a new URL every time when it's called
especially to prevent any type of caching, any type of caching is excluded
to protect the privacy, but I can do nothing to the return back feature.
This bug kills the whole security. Why IIS is so crazy to return the page
from some cache in place of a new calculated page according to the new
combination login/password? Any ideas how to avoid this issue? The operating
system on the server is Windows 2000 Advanced Server. My local system where
this issue doesn't appear is Windows XP Pro. If I connect to the remote
server ragardless of the machine and/or operating system I'm receiving this
issue. But why? If I check the option mentioned above in - "Do no save
encrypted pages to disk" it works great. A new M$ hole or something?

I also see in debugger that if I click the Backspace button the previous
page "supposes" that there were no a postback and executes a short schema
skipping the if (!IsPostBack){}. Maybe I should play with it closer? Did
anybody see this kind of issues and what was the solution?

Just D.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Text inline.

Here is a question. I don't see any problem if I start this app on my
local computer against my local IE both in debug or release modes. If I
upload the same app to my corporate server where it works under HTTPS here
are a few possible ways.

1. It works just great if the Advanced Internet option "Do not save
encrypted pages to disk" is checked on.
2. If I uncheck this option then it still works if I run it on my local
IIS against my local IE,

What error you see when uploaded to the server?

3. ... but if I run this app against my corporate server with my local IE
then here is a very interesting bug. I'm able to login as one client using
his login/password, then I can click the Backspace button, get the login
page again, enter another login/password, then click OK and get the page
belonging to the first patient like it was already stored in some buffer
and returned back to me. All pages and the whole app are configured to
ignore the cache, all aspx pages are having this tag:

<meta http-equiv="CACHE-CONTROL" content="NO-CACHE">

Post the code you are using in the page, I bet this is a programming error
more than a OS matter.
Just to be sure, do a Session.Abandon() before checking the login/password
this will assure you that the previous session will be discarded.

No results at all! What's going on? Is the operating system too stupid to
cache pages inside one session and ignore all settings made right in the
program code? It doesn't happen if I call new pages one by one, the app is
written so that it generates a new URL every time when it's called
especially to prevent any type of caching, any type of caching is excluded
to protect the privacy, but I can do nothing to the return back feature.
This bug kills the whole security. Why IIS is so crazy to return the page
from some cache in place of a new calculated page according to the new
combination login/password? Any ideas how to avoid this issue? The
operating system on the server is Windows 2000 Advanced Server. My local
system where this issue doesn't appear is Windows XP Pro. If I connect to
the remote server ragardless of the machine and/or operating system I'm
receiving this issue. But why? If I check the option mentioned above in -
"Do no save encrypted pages to disk" it works great. A new M$ hole or
something?

Again the back button is dependand of the browser, not IIS, you have to live
with that.

I also see in debugger that if I click the Backspace button the previous
page "supposes" that there were no a postback and executes a short schema
skipping the if (!IsPostBack){}. Maybe I should play with it closer? Did
anybody see this kind of issues and what was the solution?

When you use the "back" button the browser just load the cached document he
has, no request is made to the server, it has been like that always.


cheers,

 

[Guest]

Caching occurs in 3 places when dealing with web pages: on the server, on the
client, and on an intermediate proxy server. The no-cache stuff you set only
affects the browser. It simply tells the browser to not cache the page. You
should be able to confirm that the browser is not caching the page by looking
in your temp IE directory. When you click the Back button the browser goes
there first irrelevant of anything else.

Once you have verified that the page itself is not being cached then you
need to confirm that IIS is not caching the page. You can verify this by
looking in the IIS settings for the expiration of pages. Note that setting
this globally could have a dramatic effect on performance.

Finally you need to deal with the proxy server. Chances are that your
corporate IIS box uses a proxy server but I doubt that you are running one
locally so this is probably where the problem lies. When a page request is
sent to the IIS box the proxy server will intercept the request and see if it
has a cached copy of the page (this is not affected by the no-cache option
you set). If it has a copy then it returns the copy otherwise it'll pass the
request on to IIS. To disable proxy caching you need to add some more
pragmas to your page.

In .NET you can remove the various no-cache pragmas and what not from your
page. They won't meet your need in this case. Instead use
HttpCachePolicy.SetCacheability(HttpCacheability.NoCache). This will force
the page to be retrieved from the server every time irrelevant of IE or proxy
settings. It does not map to no-cache.

I haven't played around with this stuff too much but that is how I
understand it. Hope it helps.
Michael Taylor - 9/7/05

 

[Just D.]

Hi,

When you use the "back" button the browser just load the cached document
he has, no request is made to the server, it has been like that always.

Not exactly, some secure web sites don't allow to use the Backspace button
showing that the content of the page is expired. Just expiration, a
time-to-live tag or something else?

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message
Just D.
AZ

 

[Just D.]

Thanks Michael,

I will try your advice:

HttpCachePolicy.SetCacheability(HttpCacheability.NoCache).

Sounds like a good idea. For sure we're not using any cache system on both
sides, the provider doesn't use any proxy or something, otherwise the
traffic would kill it. Anyway I asked the provider about it a couple years
ago. I'm sure that this is the IE bug, I tried Opera yesterday, almost all
controls don't work properly but the credentials work fine, so this is this
feature of the IE - "Do not save encrypted pages to disk", if it's disabled,
only then I see the issue.

Just D.
AZ.

 

[Just D.]

Here is a little bit better, take a look;

HttpCachePolicy.SetCacheability(HttpCacheability.NoCache).

http://support.microsoft.com/kb/q234067/

http://support.microsoft.com/kb/222064/

Just D.

 

[Juan T. Llibre]

Instead of using :
<meta http-equiv="CACHE-CONTROL" content="NO-CACHE">

Have you tried using : Response.Cache.SetNoStore ();



Juan T. Llibre
ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
===========================

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Juan,

Nice to see you outside the CH


cheers,

 

[Juan T. Llibre]

Hi, Nacho.

I'm here every day...

Nice to see *you* here.

;-)



Juan T. Llibre
ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
==========================

 

[Damien]

Thanks Michael,

I will try your advice:

HttpCachePolicy.SetCacheability(HttpCacheability.NoCache).

Sounds like a good idea. For sure we're not using any cache system on both
sides, the provider doesn't use any proxy or something, otherwise the
traffic would kill it. Anyway I asked the provider about it a couple years
ago. I'm sure that this is the IE bug, I tried Opera yesterday, almost all
controls don't work properly but the credentials work fine, so this is this
feature of the IE - "Do not save encrypted pages to disk", if it's disabled,
only then I see the issue.

Just D.
AZ.

Opera/Controls - have you updated browserCaps in machine config? If
not, go to http://slingfive.com/pages/code/browserCaps/ or somewhere
similar and follow the instructions. Note that one bad one to try is
the site mentioned just above browserCaps. The updates never appeared.

Damien