P
praveen
Hello and thank you in advance for your reply!
Summary:
--------
Unable to eliminate "Page Unavailable" errors when a user hits on the
Browser "Back" button in Internet Explorer.
App Overview:
-------------
A Stateful Session Bean & CMP based J2EE application using Struts 1.1
application built using WSAD 5.0.1 Integration Edition, talking to a
DB2 8.1 UDB and deployed on WAS 5.0.2 EE.
Browser - Internet Explorer 6.x on Windows XP SP1.
Problem:
--------
Although I implemented a collections based "Back" button
concept(Allowing the user to physically store page names from the
start of the business process till the end of the submission and then
clearing the stack!) to implement the "back-button" functionality on
the page to override the Browser back button, my superiors insist that
I "Do something" about making the browser's back button to work with
the App without any "Page Unavailable" errors and manual page
refreshing!
I have tried "googled" solutions, including the following from
struts-user groups etc.:
1. Physically setting the META headers "Cache-Control" and "Pragma" as
per W3C recommendations in the JSP's.
2. Using servlet response to set headers with expiration date to the
past, and including the headers outlined in solution 1. above.
3. Adding <controller> tag entry and setting nocache=false
i.e. <controller nocache="false" /> in struts config. (Should I try
including it within the <action> tags under ActionServlet ?)
I have implemented a Synchronizer pattern, and hence
redundant/duplicate form submissions are not a problem for me.
I have been trying to enable this feature but couldn't find any proper
answers. Although "Struts in Action" refers to programmatically
altering the RequestProcessor by extending it and then altering the
default controller settings (overriding processNoCache method), I
can't find anything else. If there is a easier way, I would appreciate
if any of you can share your thoughts on this.
Some say that this is a IE bug (headers greater than 64 kb get ignored
and IE reverts to default settings), the explanation of which I am not
satisfied with!
A quick response is appreciated!
Thanks..
Praveen
Summary:
--------
Unable to eliminate "Page Unavailable" errors when a user hits on the
Browser "Back" button in Internet Explorer.
App Overview:
-------------
A Stateful Session Bean & CMP based J2EE application using Struts 1.1
application built using WSAD 5.0.1 Integration Edition, talking to a
DB2 8.1 UDB and deployed on WAS 5.0.2 EE.
Browser - Internet Explorer 6.x on Windows XP SP1.
Problem:
--------
Although I implemented a collections based "Back" button
concept(Allowing the user to physically store page names from the
start of the business process till the end of the submission and then
clearing the stack!) to implement the "back-button" functionality on
the page to override the Browser back button, my superiors insist that
I "Do something" about making the browser's back button to work with
the App without any "Page Unavailable" errors and manual page
refreshing!
I have tried "googled" solutions, including the following from
struts-user groups etc.:
1. Physically setting the META headers "Cache-Control" and "Pragma" as
per W3C recommendations in the JSP's.
2. Using servlet response to set headers with expiration date to the
past, and including the headers outlined in solution 1. above.
3. Adding <controller> tag entry and setting nocache=false
i.e. <controller nocache="false" /> in struts config. (Should I try
including it within the <action> tags under ActionServlet ?)
I have implemented a Synchronizer pattern, and hence
redundant/duplicate form submissions are not a problem for me.
I have been trying to enable this feature but couldn't find any proper
answers. Although "Struts in Action" refers to programmatically
altering the RequestProcessor by extending it and then altering the
default controller settings (overriding processNoCache method), I
can't find anything else. If there is a easier way, I would appreciate
if any of you can share your thoughts on this.
Some say that this is a IE bug (headers greater than 64 kb get ignored
and IE reverts to default settings), the explanation of which I am not
satisfied with!
A quick response is appreciated!
Thanks..
Praveen