RE: "Page Cannot Be Displayed" error with IE XP SP2

An update, in case anyone out there is interested in broken web applications:

The trigger for this is the presence of "cache-control" set to "no-cache" in
the HTTP response header (the <meta> tags turn out to have nothing to do with
it). If you have this in your header and submit a POST from the page, then
use the back button, you will (at least most of the time, with the browser
identified below) get the "This Page Cannot Be Displayed" error.

(I tested this using a bare-bones JSP on Weblogic. I'm sure you Microsoft
server types can do the same with ASP and IIS.)

This is going to irritate the bleep out of some of my customers. The
application framework I work on is written in such a way that virtually every
page is generated due to a POST. Now a consistent browser would not let you
use the back button to return to a page that was generated by a POST, but IE,
as we all know, allows you to do this while it has the previous page cached
in memory. So even though I shouldn't have to, I'm forced to disable caching
on all of my pages. And now the latest, greatest version of IE throws up all
over my app.

Suggestions as to a workaround would be greatly appreciated.

"Christopher Luebcke" wrote:

> Hi all, sorry in advance if this isn't the correct forum, but it looks like
> the closest one that actually gets traffic.
>
> I have a web application that uses a POST for virtually every page request.
> I also disable caching on every page (setting both HTTP headers and <meta
> http-equiv>s, using both pragma=no-cache and cache-control=disabled).
>
> What I'm running into is that when a user uses the back button to return to
> a page that was itself generated via a POST request, they're getting the
> message "This Page Cannot Be Displayed". This is a browser error screen, not
> an HTTP response from the server.
>
> This only occurs in IE 6, XP SP2 (the 2900.2180 version). I've found one
> machine with that browser that doesn't experience the problem, and about six
> that do. I can't find any difference between the exception and the other
> machines that comprise the rule.
>
> All the affected browsers have their security and cache settings on "Medium"
> with no custom settings. I've looked through Advanced settings and can't find
> anything unusual, and not that differs between affected and non-affected
> machines. Also tried deleting the cache, to no avail.
>
> Any help or suggestions for further inquiry would be greatly appreciated. I
> have customers who are starting to notice this behavior and it's getting
> uncomfortable (in my particular case this also causes the user to lose their
> application session, but I'm guessing that's because the POST data never gets
> resent, and my app treats that as a new session).
>
>
.