Browser Back Button (IE) Caching Problem in Struts Land

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
 
A

Andrew Thompson

...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 will cede to the server-side gurus on this one,
(I have done a smattering of Java server-side
and a whole lot of site design) but it actually
sounds like this might be the real problem. Not so
much the behaviour of the app., as the expectation
that it makes sense to have the back button work
in this linear web-application.

Perhaps a 'Canel Everything and return to
Main Page' button is more appropriate?
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!

So.. what have you done to test that theory?
How does the app. behave using Mozilla/Netscape
or Opera?

HTH
 
D

David Hilsee

praveen said:
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!

You, as an HTML/JavaScript/etc programmer, do not have much control over
what happens when a user clicks the back button. This is especially true if
you are relying only on HTML, or only on browser-agnostic approaches. If
anyone orders you to make the browser behave in a certain way when the back
button is clicked, I suggest telling them how hard it is to do that, unless
there is a straightforward and standard (cross-browser) way to do what they
want. The "Page Unavailable" errors that you are describing sound very
difficult to deal with. Even when you fix that problem, I would be
surprised if it worked with other browser, other versions of IE, other
browsers, or even with other similar-looking problems. If it does work with
every client configuration you have to deal with, then consider youself
lucky, and go with it.
 
P

praveen

Andrew:

I have implemented a "Cancel" and a "Back" button within the scope of
the page-flow too, but apparently, the end-users are so fond of that
darned "Back" button which I am sure users will love, but programmers
hate! :)

As for testing, I haven't done behavioral testing per se to verify the
bug in IE, largely due to the fact that I ran out of time trying to
salvage an older code base by a "renegade" consultant [:)] and
refactor it into a robust and a performance oriented J2EE/Struts app.
To top it off, Internet Explorer is the standard across the
client-site!



David:

I can't agree with you more! Apparently, there is a "battle of apps"
in the making since the App I am building is supposed to be a new
release of an older JSP & Servlets based App (Model 1 per se!).

Nonetheless, I am certain that there should be a way, since
multiple/duplicate form submission due to cache problems can easily be
controlled by using the Synchronizer pattern! Clients rarely care
about technology constraints and look forward to an easy and a
navigable GUI!

On a serious note [:)], If I can't make it happen, I can't sleep
soundly without knowing why I couldn't make it happen!




Thank you both for your comments! Hope you guys have a wonderful day..

Praveen
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top