Ok, thanks for the heads-up, I added it to the constraint.
Nathan
On 30/06/16 17:10, Chris Poulsen wrote:
btw the modules path can be both "modules" and "modules.gz" depending
on various things.
On Thu, Jun 30, 2016 at 4:35 PM, Nathan Quirynen
<nat...@pensionarchitects.be <mailto:nat...@pensionarchitects.be>> wrote:
Hey Chris,
Yeah, that's the only option I've found until now using following
check as you said:
if( ! (path.startsWith("/assets/") ||
path.startsWith("/modules.gz/")) ) {
// add headers
}
Hope I got everything covered by this, but it's at least an
improvement as how it was before (caching was turned off for
everything) and the problem I had with that one asset seems to be
solved (still don't really get what was happening there though).
Thanks for your thoughts!
Nathan
On 30/06/16 15:56, Chris Poulsen wrote:
check the path? (asset paths usually contains "/asset/" and
module paths
contains "/modules/")
On Thu, Jun 30, 2016 at 11:55 AM, Nathan Quirynen <
nat...@pensionarchitects.be
<mailto:nat...@pensionarchitects.be>> wrote:
Is there any way to know in a Request filter if it is a
page request (not
a request to some asset).
I thought doing the following:
PageRenderRequestParameters parameters =
linkEncoder.decodePageRenderRequest(request);
if (parameters == null) {
// not a page request
}
But it seems that for every request to an asset it is
never null, and
parameters.getLogicalPageName() has the value "Index".
On 29/06/16 18:32, Nathan Quirynen wrote:
I have found that in one of the applications request
filters following is
added to every response:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
On 29/06/16 17:33, Nathan Quirynen wrote:
Hi,
I have a "weird" problem where this one image
won't show up. Never had
this problem before the upgrade to 5.4 and since
there have been changes
with caching, I guess it has something to do with
that.
I don't know a lot about the caching Tapestry does
(or in general), so I
hope someone can point me in the right direction
to find the problem.
After some testing the image does not load when I
use Firefox, unless I
use the reload function of Firefox that overrides
the cache.
The difference I find when using this is in the
request headers (for all
files):
Normal load (image does not show up):
Cache-Control: max-age=0
"Hard" reload (image does show up):
Cache-Control: no-cache
Pragma: no-cache
When inspecting the source code in Firefox, the
url seems correct and
then the image does show up magically.
What could be causing this one file (next to all
the other assets that
were added in the same version) to have this
behaviour? Can this be caused
by Tapestry?
I have tried clearing Firefox's cache, using a
computer that has not
opened the application before and also changing
the version of the
application with no results...
Some pointers are appreciated!
Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tapestry.apache.org
<mailto:users-unsubscr...@tapestry.apache.org>
For additional commands, e-mail:
users-h...@tapestry.apache.org
<mailto:users-h...@tapestry.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tapestry.apache.org
<mailto:users-unsubscr...@tapestry.apache.org>
For additional commands, e-mail:
users-h...@tapestry.apache.org
<mailto:users-h...@tapestry.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscr...@tapestry.apache.org
<mailto:users-unsubscr...@tapestry.apache.org>
For additional commands, e-mail:
users-h...@tapestry.apache.org
<mailto:users-h...@tapestry.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
<mailto:users-unsubscr...@tapestry.apache.org>
For additional commands, e-mail: users-h...@tapestry.apache.org
<mailto:users-h...@tapestry.apache.org>
