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> 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> 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
>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
