[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brendan Healey commented on RF-11888:
-------------------------------------
I'm really starting to see this as a critical problem. I've got everything setup
so that my static resources cache properly. In web.xml I set
com.sun.faces.defaultResourceMaxAge
to 31536000000 (a year), and in a filter I set the response header Cache-Control to
"max-age=31536000, public, must-revalidate".
I then see the browser using the cache rather than issuing a request. The browser has
calculated an expiry date for the cached resource, and I expect that it will carry on
using the cache rather than issuing a new request for the resource until the expiry
date is reached.
Which raises the question how do I invalidate the browser cache in the case that I've
upgraded richfaces? I clearly don't want to be using an old version of packed.js if
I've
upgraded from RF 4.1 to 4.2.
For all my other resources I will just increment the version string in my resource
handler
whenever necessary, but I don't see any way to achieve the same for the richfaces
resources
because of this problem.
Resource Servlet can't handle query string appended to resource
url
-------------------------------------------------------------------
Key: RF-11888
URL:
https://issues.jboss.org/browse/RF-11888
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: resource handling
Affects Versions: 4.1.0.Final
Environment: Glassfish 3.1.1 (NO Tomcat)/Mojarra 2.1.3 Chrome browser -
Reporter: Brendan Healey
A custom resource handler (
http://blogs.oracle.com/rlubke/entry/jsf_2_0_new_feature)
can be used to append a version string (i.e. ?v=23) to a resource url to force a
browser to refresh a resource rather than use any cached version.
This is useful as a last resort strategy, perhaps after a major redeployment, and
also in the event that there are other problems setting useful ETag and Last-Modified
http response headers.
At present any appending of a version string causes a 404 response status, for example:
Request URL:
https://localhost:8181/MyApp/org.richfaces.resources/javax.faces.resource...
Removing the url parameter makes it work ok. As you can see I have resourceMapping
enabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira