I assume you mean browser page caching. I came across this problem with an
application that required a login to see customer transaction data.
Essentially you could login, view financial data and then log out, after which
hitting the back button would show browser cached pages from the previous
session. Obviously this caching could potentially reveal sensitive data to a
user other than the original customer.
Adding the following meta tags to all my pages (regardless of whether they
contained forms, s:link, etc) prevented the browser from caching the pages:
meta http-equiv=Expires content=-1 /
| meta http-equiv=Cache-Control content=no-cache /
| meta http-equiv=Pragma content=no-cache /
This worked well and our application functioned normally after retro fitting
the meta tags, however it did cause a problem for our client which may or may
not be an issue for you. Our application made heavy use of the commandLink for
navigation. This mechanism requires a HTTP post when the link is selected. The
side effect of this is that whenever the user selects the browsers' back
button, after adding the meta tags the browser has to request a fresh page from
the server. Because the original page was generated as the result of a HTTP
post, this causes the browser to issue a Resend Posted information warning
(or something like that) every time the back button is used. This is ugly and
is not particularly intuitive and was unacceptable to our client
(understandably).
We got around this by replacing all commandLinks that were used purely for
navigational purposes with s:link. s:link generates a regular HTML link that
allows navigation using HTTP get which solves the browser message problem. One
caveat to this solution is that if any navigation requires values from other
components on the page or those values are to be saved for later you still have
to use commandLink to submit the form data.
Regarding performance: in our case (in fact most cases), security requirements
superseded performance requirements, so we had no choice but to turn off
browser page caching. That said, you can still get good performance by adopting
one or more of the following:
1. As mentioned in previous posts, if a page is particularly expensive to
render then caching the expensive page fragments using s:cache is a simple and
very effective strategy (e.g. a table bound to a datamodel that requires a
complex database query).
2. Introducing appropriate caching policies for external page resources
(css, js, images etc) can help to reduce unnecessary server requests and save
bandwidth.
3. If your generated pages are large and your users? connections are slow
you could add a compression filter to your application. I've used the
following compression filter successfully in a Seam application which will cut
HTML page sizes by 80% over the wire:
http://sourceforge.net/projects/pjl-comp-filter/
Hope this helps,
Chris.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4012560#4012560
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4012560
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
