Resources first checked against server not retrieved from cache right away

Question

Resources that are in ui:insert's,ui:include's are not cached. While the other stuff that is defined in my template is. The resources that are accessed in the ui:'s do have the right "Expires"-header, but they also have Cache-Control:no-cache & Pragma:No-cache. The other resources that are not accessed in the ui:insert and ui:include don't have this, like the stylesheets and js in the header. Now and then some random resources in the ui:'s do get from the cache, like 2 out of 12. And those 12 images are defined exactly the same way, I don't get why those 2 would get cached.

I have tried everything I can, and can't figure it out. (Mojarra 2.2.12 is used)

The param javax.faces.PROJECT_STAGE has the value Production and the param com.sun.faces.defaultResourceMaxAge has 604800000.

Example of my main_pages_template, is use this template at various pages with the template-attribute in the ui:composition.

<html lang="#{localeBean.language}"
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://xmlns.jcp.org/jsf/facelets"      
  xmlns:h="http://xmlns.jcp.org/jsf/html"
  xmlns:f="http://xmlns.jcp.org/jsf/core">
<f:view locale="#{localeBean.language}">
    <h:head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <h:outputStylesheet library="css" name="default.css"/>
        <h:outputStylesheet library="css" name="cssLayout.css"/>
        <h:outputScript library="js" name="locales.js"/>
        <title><ui:insert name="title">Facelets Template</ui:insert></title>

        <ui:include src="/WEB-INF/templates/favicon.xhtml" />

    </h:head>

    <h:body id="secure">

        <div id="wrapper">
            <div id="top">
                <ui:include src="/WEB-INF/templates/header_template.xhtml" />
            </div>

            <div id="content" class="center_content">            
                <ui:insert name="content">Content</ui:insert>
            </div>

            <div id="footer">            
                <ui:include src="/WEB-INF/templates/footer_template.xhtml" />
            </div>
        </div>

    </h:body>
</f:view>

Edit: Expample of the headers of an image that is not retrieved from the cache.

Response headers:

Cache-Control:no-cache
Content-Length:6607
Content-Type:image/png
Date:Fri, 15 Jan 2016 15:55:26 GMT
ETag:W/"6607-1452873128742"
Expires:Sun, 14 Feb 2016 15:55:26 GMT
Last-Modified:Fri, 15 Jan 2016 15:52:08 GMT
Pragma:No-cache
Server:GlassFish Server Open Source Edition  4.0
X-Powered-By:Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition  4.0  Java/Oracle Corporation/1.8)

Request headers:

Accept:image/webp,image/*,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:JSESSIONID=5ff7d3adafb1d4c47c82149f04c8; JSESSIONID=a56f8de3d3ad495ef464b309b91a; treeForm_tree-hi=treeForm:tree:resources:mailResources
Host:localhost:8080
If-Modified-Since:Fri, 15 Jan 2016 15:52:08 GMT
If-None-Match:W/"6607-1452873128742"
Referer:http://localhost:8080/webapp/secure/profile
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Which JSF impl/version? Tried the latest to exclude a long fixed bug from being the cause? GlassFish 4.0 is pretty old. — BalusC, Jan 15 '16 at 16:09
I explicitly asked which JSF impl/version. "JSF 2.2" is just a spec version. There are 2 main implementors, Mojarra and MyFaces, which in turn have various 2.2.x versions. Latest are 2.2.12 resp 2.2.9. Have you tried them? — BalusC, Jan 15 '16 at 16:17
I think it's Mojarra? I am note sure, based on this: "xmlns:ui="http://java.sun.com/jsf/facelets" I picked this project up at my internship never knowing that JSF is a spec... — Wesley Egbertsen, Jan 15 '16 at 16:22
@BalusC Initializing Mojarra 2.2.0 ( 20130502-2118 https://svn.java.net/svn/mojarra~svn/tags/2.2.0@11930) for context — Wesley Egbertsen, Jan 18 '16 at 08:43
Instead of using the ui:include for the header, I tried just putting the content from the header directly in the div with the id "top", it stil didden't cache those image. I also tried clearing the whole browser cache and see if it was something browser related, but no luck. — Wesley Egbertsen, Jan 18 '16 at 08:52
Now this is debugging and creating an [mcve], congrats, but it means your total question is kind of invalid, right? — Kukeltje, Jan 18 '16 at 09:09
I did that and it now says: "Initializing Mojarra 2.2.12". But I still have the same caching problem. — Wesley Egbertsen, Jan 18 '16 at 09:50
http://i.imgur.com/VCXe1ru.png - Here is a picture of the files, everytime it happends to the same files. Rest get cached those not. — Wesley Egbertsen, Jan 18 '16 at 09:52
which ones are not good? I see "200's" that actually come from the cache and 304's that (after a check on the server) come from the cache to... So you actually want to prevent the check to be done as well? http://stackoverflow.com/questions/20978189/how-304-not-modified-works — Kukeltje, Jan 18 '16 at 09:59
The btn_ images are a menu with a hover image change. So if a user would hover over the menu it would everytime check with the server if the image was modified. So I don't understand why it won't take the images from the cache as it does with the other resources. — Wesley Egbertsen, Jan 18 '16 at 12:45
@BalusC I get the same problem with GlassFish 4.1.1 and Mojarra 2.2.12 — Wesley Egbertsen, Jan 18 '16 at 15:02
It's probally related to this: http://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests ? — Wesley Egbertsen, Jan 18 '16 at 15:30
your question and especially the title, is now totally not in line with the answer. Can you try to make it more generic? — Kukeltje, Jan 18 '16 at 16:38

score 2 · Accepted Answer · edited May 23 '17 at 12:15

2

I figured out that the server was responding with Cache-Control: no-cache and Pragma: no-cache because the resources were accessed on a secure page that was defined by a GlassFish Security Realm (j_security_check).

To solve this I implementend the solution here: Static resources are not cached referenced from glassfish secure page

I added <property name="securePagesWithPragma" value="false" /> as a property from glassfish-web-app in the glassfish-web.xml. Now only the Cache-Control header is set with the value, private which is fine. Private means that only the end user can cache it and not inbetween proxies.

edited May 23 '17 at 12:15

Community

1
1

answered Jan 18 '16 at 15:55

Wesley Egbertsen

720
1
8
25

This is not the default behavior. Something else in your webapp or even the server itself is setting those no-cache headers. So what you've done is merely a workaround, not a solution. – BalusC Jan 18 '16 at 18:58
@BalusC Could it be that, because these resources are accesed from secure pages (security contstraint)? I am using GlassFish Security Realm (j_security_check). It would make sense because on the login page, that is publicly accessible, I do not seem to have caching problems. Could it be related to this http://stackoverflow.com/questions/5468099/static-resources-are-not-cached-referenced-from-glassfish-secure-page/5482987#5482987 ? – Wesley Egbertsen Jan 18 '16 at 20:31
I think it does, but searching around the internet, I can't really find at what place in my glassfish-web.xml I should place it. When I get back at work tomorrow, I will just try to add `` as a child for glassfish-web-app. – Wesley Egbertsen Jan 18 '16 at 20:32
Oh that. I recall it. Awkward indeed. Surprising it still occurs on latest GF. – BalusC Jan 18 '16 at 20:34
I think it does, as I also tried running my WebApp on the latest GlassFish with the Latest Mojarra, and I still had the caching issue. Here http://goo.gl/w23aqd is stated that indeed those two headers would be set to no-cache. The default value of it is true, so I think i've found the culprit? – Wesley Egbertsen Jan 18 '16 at 20:37
Yep, GF is the culprit, not JSF. – BalusC Jan 18 '16 at 20:39
@BalusC Updated my answer. – Wesley Egbertsen Jan 18 '16 at 21:12

Resources first checked against server not retrieved from cache right away

1 Answers1