Caching problem?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Caching problem?

nquirynen
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Caching problem?

nquirynen
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Caching problem?

nquirynen
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Caching problem?

Chris Poulsen
check the path? (asset paths usually contains "/asset/" and module paths
contains "/modules/")

On Thu, Jun 30, 2016 at 11:55 AM, Nathan Quirynen <
[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Caching problem?

nquirynen
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 <
> [hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Caching problem?

Chris Poulsen
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 <
[hidden email]> 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 <
>> [hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Caching problem?

nquirynen
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
> <[hidden email] <mailto:[hidden email]>> 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 <
>         [hidden email]
>         <mailto:[hidden email]>> 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:
>                     [hidden email]
>                     <mailto:[hidden email]>
>                     For additional commands, e-mail:
>                     [hidden email]
>                     <mailto:[hidden email]>
>
>
>
>                 ---------------------------------------------------------------------
>                 To unsubscribe, e-mail:
>                 [hidden email]
>                 <mailto:[hidden email]>
>                 For additional commands, e-mail:
>                 [hidden email]
>                 <mailto:[hidden email]>
>
>
>
>             ---------------------------------------------------------------------
>             To unsubscribe, e-mail:
>             [hidden email]
>             <mailto:[hidden email]>
>             For additional commands, e-mail:
>             [hidden email]
>             <mailto:[hidden email]>
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>