1

i've seen:

How to control web page caching, across all browsers? enter link description here

I've used in JSF 1.2 pages:

<meta http-equiv="Cache-control" content="no-store, no-cache, must-revalidate"/>
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="-1"/>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"/>

It did not work in IE8 e Chrome! When I use the back button it shows the page again! What is wrong? Regards.

Community
  • 1
  • 1
Fernando Franzini
  • 23
  • 8

1 Answers1

3

Here's a cite from How to control web page caching, across all browsers? which you linked in your question but apparently overlooked:

Note that when the page is served over HTTP and a header is present in both the HTTP response headers and the HTML meta tags, then the one specified in the response header will get precedence over the HTML meta tag. The HTML meta tag will only be used when the page is viewed from local disk file system. See also W3 HTML spec chapter 5.2.2. Take care with this when you don't specify them programmatically, because the webserver can namely include some default values. To verify the one and other, you can see/debug them using Firebug Net panel.

This is apparently the case. You need to set those headers on the real HTTP response, not in its HTML output. In case of a JSF 1.x web application the best way is to create a servlet filter to perform the task. Here's a kickoff example:

public class NoCacheFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
        response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
        response.setDateHeader("Expires", 0); // Proxies.
        chain.doFilter(req, res);
    }

    // ...
}

Map it in web.xml on an URL pattern of interest, e.g. *.jsf or on the servlet name of the FacesServlet.

Community
  • 1
  • 1
BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452
  • "This is apparently the case. You need to set those headers on the real HTTP response, not in its HTML output." I'll remove from jsp and set in a serlvet filter. Then say if it worked or not. Thanks! – Fernando Franzini May 18 '12 at 19:16
  • Because the webserver has apparently set some default values, because your webapp hasn't explicitly set them on the HTTP response. The webserver's behaviour is out of your control. You need to set them explicitly in your webapp. You can use Firebug (and Chrome or IE9) to see the real HTTP response headers in the webdeveloper toolset. See also the screenshot in the linked answer. – BalusC May 18 '12 at 19:33
  • hi BalusC I need Help. I used your solution as already spoken for me here ... but I realized that broke the application in IE8. The problem is this .... all my downloads in PDF, XLS stopped working only in IE8 .. (in other browsers it's all ok). After giving some research I found the following text at the microsoft site: – Fernando Franzini May 29 '12 at 18:22
  • "When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer applies to any request no-cache. If the header or headers are present, Internet Explorer does not store the cached file. Consequently, can not open the file. Sites that want to allow this type of operation should remove the header or the no-cache headers." Do you have any idea how I could keep the no-cache successfully overcome this situation? Best Regards. – Fernando Franzini May 29 '12 at 18:22
  • You should of course not put those headers on the downloads, but only on the JSF pages. If you happen to manually serve files for download by a JSF backing bean, then you need to explicitly set the cache headers in the bean's action method. – BalusC May 29 '12 at 18:27
  • See also http://stackoverflow.com/questions/5034454/internet-explorer-cannot-download-the-file-served-by-jsf – BalusC May 29 '12 at 19:02
  • HttpServletRequest rq = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) res; if (rq.getAttribute(CACHE_HTTP) == null) { response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. response.setHeader("Pragma", "no-cache"); // HTTP 1.0. response.setDateHeader("Expires", 0); // Proxies. } else { response.setHeader("Cache-Control", "public"); response.setHeader("Pragma", "public"); } What do you think? – Fernando Franzini May 29 '12 at 19:31
  • No, not in the filter. The filter should be applied on JSF request only, not on the file download requests. So the filter should be mapped to the `FacesServlet`. Keep the filter's code as is. If you're manually serving files for download in a JSF backing bean action, then you should set the headers there in the action method. – BalusC May 29 '12 at 19:36
  • I have hundreds of generations of PDF! I believe it is easier I pass a flag into the Request Scope, making the filter to generate another set of HEADER. – Fernando Franzini May 29 '12 at 19:44
  • You surely have a single method which streams the PDF to the response? Or do you have all copypasted/duplicated code throughout your webapp? – BalusC May 29 '12 at 19:45
  • Unfortunately the PDF generation (iReport) code is not centralized in a single component, being segregated into several ManagedBeans. – Fernando Franzini May 29 '12 at 19:52