7:08 a.m.
Brendan Healey created RF-11888:
-----------------------------------
Summary: 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
5:22 p.m.
[
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
5:39 p.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brendan Healey updated RF-11888:
--------------------------------
Priority: Critical (was: Major)
Description:
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done.
was:
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.
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
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done.
--
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
5:41 p.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brendan Healey updated RF-11888:
--------------------------------
Description:
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
was:
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done.
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
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
3:01 p.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brian Leathem commented on RF-11888:
------------------------------------
Note: When you upgrade from version 4.1 to 4.2, the URL for packed.js will change:
https://localhost:8181/MyApp/org.richfaces.resources/javax.faces.resource...
Not the RichFaces version in the URL.
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
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
3:01 p.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brian Leathem reassigned RF-11888:
----------------------------------
Assignee: Lukáš Fryč
Lukas, please assess and schedule accordingly.
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
Assignee: Lukáš Fryč
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
4:17 p.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brendan Healey commented on RF-11888:
-------------------------------------
Note: When you upgrade from version 4.1 to 4.2, the URL for packed.js
will change:
Hello Brian, that's a very good point - that definitely takes the edge off my
concerns, I should have realised this myself, too much coding. Thanks.
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
Assignee: Lukáš Fryč
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
6:09 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč commented on RF-11888:
---------------------------------
You certainly don't need to append version suffix for RichFaces pre-generated
resources,
but for other resources served by ResourceServlet, you might want to.
We are limiting what query parameters can be appended to ResourceServlet managed requests
since there are security implications when user could append whatever query param (like
{{ln=*}}).
However I'm open to discuss addition of some safe attributes like {{v=*}}
which would enable us to use versions with custom resources served by ResourceServlet
(refered to as "resource mapping" feature).
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
Assignee: Lukáš Fryč
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
6:09 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč reassigned RF-11888:
-------------------------------
Assignee: (was: Lukáš Fryč)
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
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
10:35 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brian Leathem commented on RF-11888:
------------------------------------
Brendan, there are two paths forward:
# close this ticket as the RichFaces version in thi URL is sufficient for your use case
# add a version (v) attribute to the list of attributes pared by the ResourceServlet
Since you opened this ticket, can you indicate which direction you would prefer it to
proceed?
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
Priority: Critical
Labels: waiting_on_user
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
6:09 p.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brendan Healey commented on RF-11888:
-------------------------------------
Hello Brian, apologies for not responding earlier and thanks for the follow up.
Here's
my perspective. My initial bug report was clearly erroneous in that I'd fixated on
the
appending of a version string and failed to take into account the fact that the URL
contains the richfaces release version. As such my concerns that stale richfaces
resources
with a long max-age (set by my application) could be served from browser cache following
a richfaces upgrade were invalid.
On this basis I'd be happy for the ticket to be closed. However...
I think you need to consider the fact that unless you are able to handle the appending
of a version string you'll be fielding a slow but steady stream of enquiries from now
to eternity.
As part of the very simple implementation of the ResourceHandler interface you have to
extend the ResourceHandlerWrapper class and override the createResource() method. In this
method you will deal with any exclusions, any URLs to which you do not wish to append a
version string. Here is the implementation I use:
@Override
public Resource createResource(String resourceName, String libraryName) {
Resource resource = super.createResource(resourceName, libraryName);
if(resourceName.equals("jquery.js") || (libraryName != null &&
(libraryName.equals("org.richfaces") ||
libraryName.equals(SQCC_LIBRARY)))) {
return resource;
}
else {
return new CustomResource(resource);
}
}
The thing that is that when you use <h:outputScript name="jquery.js"/> you
are using jquery
bundled with the richfaces libraries, as we all know. When you're using resource
mapping it's
this <h:outputScript ../> tag which triggers the loading of packed.js, not the first
richfaces
component on the page.
I'm already seeing people on the forum hitting this problem where they get the
'jsf is undefined'
error, which can be alleviated by using <h:outputScript library="javax.faces"
name="jsf.js" before
<h:outputScript name="jquery.js"/>.
Although entirely logical, especially with the benefit of hindsight, it's not
immediately
obvious that using the richfaces jquery is going to load the packed/compressed richfaces
resources.
As relevant to the resource handler, as you can see from my implementation of the
createResource()
method above that it's presently necessary to exclude the resource name (not the
library name)
"jquery.js" from having a version string appended, or it won't work.
I'd say this took me half a day to fully debug and put a workaround into place, so the
question
is whether you wish to proliferate this scenario for other developers, or just handle the
version
string. I recommend the latter option.
Thanks for your help.
Brendan.
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
Priority: Critical
Labels: waiting_on_user
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
2:47 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč commented on RF-11888:
---------------------------------
Hi Brendan, I can see two actual issues in your previous comment:
1. you cannot use {{ResourceServlet}} for serving customized resources
2. when using {{<h:outputScript name="jquery.js" />}} and packaged
resources, you can simply break page
For (2), I would suggest to remove {{jquery.js}} from default packaging - we will get one
more request, but we will achieve ability to rewrite {{jquery.js}} (leading into improved
interoperability) and we will avoid issues which you mentioned.
Currently resource dependency graph starts with {{javax.faces:jsf.js -> null:jquery.js
-> ...}} so I don't see problem in excluding {{jquery.js}} from packaging.
For (1), we can go also in opposite way: define unsafe query parameters for
{{ResourceServlet}} - it comes only {{ln}} to my mind.
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
Priority: Critical
Labels: waiting_on_user
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
7:45 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč commented on RF-11888:
---------------------------------
I have opened RF-11888 to cover (2).
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
Priority: Critical
Labels: waiting_on_user
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
7:45 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč edited comment on RF-11888 at 2/3/12 8:45 AM:
---------------------------------------------------------
I have opened RF-11949 to cover (2).
was (Author: lfryc):
I have opened RF-11888 to cover (2).
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
Priority: Critical
Labels: waiting_on_user
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
11:29 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Brian Leathem reassigned RF-11888:
----------------------------------
Assignee: Lukáš Fryč
Lukas, can this issue be closed, of the work required is covered by the new jira you
opened?
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
Assignee: Lukáš Fryč
Priority: Critical
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
10:19 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč updated RF-11888:
----------------------------
Fix Version/s: 4.3-Tracking
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
Assignee: Lukáš Fryč
Priority: Critical
Fix For: 4.3-Tracking
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
10:19 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč commented on RF-11888:
---------------------------------
We should allow to provide locale/version query parameters.
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
Assignee: Lukáš Fryč
Priority: Critical
Fix For: 4.3-Tracking
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
10:19 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč edited comment on RF-11888 at 2/23/12 11:18 AM:
-----------------------------------------------------------
We should allow to provide locale/version query parameters.
This is minor change.
was (Author: lfryc):
We should allow to provide locale/version query parameters.
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
Assignee: Lukáš Fryč
Priority: Minor
Fix For: 4.3-Tracking
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
10:19 a.m.
[
https://issues.jboss.org/browse/RF-11888?page=com.atlassian.jira.plugin.s...
]
Lukáš Fryč updated RF-11888:
----------------------------
Priority: Minor (was: Critical)
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
Assignee: Lukáš Fryč
Priority: Minor
Fix For: 4.3-Tracking
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.
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 is essential to cause a browser to issue a request to the server if a static
resource is held in a browser cache and is not expired, but you've upgraded the
richfaces version. You have to have a way to invalidate the cache, and I'm not
seeing how this can be done in a sensible way. You can set the Cache-Control
no-cache header, but I'd need to do this in a way that says "I've just
upgraded
richfaces, so don't use the cache, issue a request to the server for the resource,
but cache the result and use this until the next time".
--
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
4703
days inactive
4741
days old
richfaces-issues@lists.jboss.org
18 comments
3 participants
participants (3)
-
Brendan Healey (JIRA) -
Brian Leathem (JIRA)
-
Lukáš Fryč (JIRA)