You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Thilo Tanner <th...@reprisk.com> on 2016/05/10 13:17:26 UTC
Asset Browser Caching
Hi all,
We use Tapestry mainly for internal applications. We have users working from places with very limited bandwidth (use Chrome’s „Good 2G“ network throttling to get an idea). It seems, the headers sent by Tapestry prevent the browser from caching assets. I modified OMIT_EXPIRATION_CACHE_CONTROL_HEADER, but without success (it seems, this settings is only used for assets without a checksum path). Production mode is enabled. I couldn’t find an issue in JIRA related to this problem, so maybe we’re doing something wrong here. We use a modified AssetRequestHandler to stream webjar assets from T5 submodules, but the problem is the same for core.js or any other directly loaded asset.
All inputs are welcome!
Thanks and best,
Thilo
Thilo Tanner
Technology Lead
Direct +41 43 300 54 42 <tel:+41%2043%20300%2054%2042>
Mobile +41 795064636 <tel:+41%20795064636>
thilo.tanner@reprisk.com <ma...@reprisk.com>
www.reprisk.com <https://www.reprisk.com>
RepRisk AG
Stampfenbachstrasse 42, 8006 Zürich, Switzerland
Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <https://www.reprisk.com>
Re: Asset Browser Caching
Posted by Thilo Tanner <th...@reprisk.com>.
Hi Cézary,
Thanks a lot for you hint. You were right, the Cache-Control and Pragma headers didn’t came from Tapestry but from Undertow, which we use as an embedded container to create Spring-Boot-like T5 apps. There is a setting that prevents caching for secured pages which is enabled by default when Servlet security constraints are in place (even though the asset paths itself aren’t secured). Anyway, it’s works perfectly now.
Thanks again for your help!
Best,
Thilo
Von: Cezary Biernacki <ce...@gmail.com>
Antworten an: Tapestry users <us...@tapestry.apache.org>
Datum: Dienstag, 10. Mai 2016 18:26
An: Tapestry users <us...@tapestry.apache.org>
Betreff: Re: Asset Browser Caching
Tapestry 5.4 itself never sets "Pragma" header (except Kaptcha component,
but it must be included separately and it is set only for actual CAPTCHA
images), and never sets "Cache-Control" to "no-cache, no-store,
must-revalidate" by default, though this particular header could be via
"tapestry.omit-expiration-cache-control-header" option. I recommend first
again ensuring that your NGINX proxy is not accidentally configured to add
these headers, e.g. by observing response headers directly from Java
application. Once you confirm that it is not added by the proxy, check your
own application for any custom filters/dispatchers. Or just grep all your
sources and configuration files (e.g. web.xml) for "no-cache" text. My bet
is that somebody developing or maintaining your application one day had a
problem "the page does not refresh", and solved it by adding these headers
to all responses.
Best regards,
Cezary
On Tue, May 10, 2016 at 5:10 PM, Thilo Tanner <th...@reprisk.com>
wrote:
> Hi Cezary,
>
> Thanks a lot for your feedback.
>
> In production, we currently use 5.4-beta-26. I quickly tried 5.4.1
> yesterday, but the problem stays the same. Below the headers sent by our
> application for core.js for example (proxied through nginx, but the headers
> are the same locally). Etag looks good, Expires as well (not sure if
> current browsers like 10 years). To me, the Cache-Control header is the
> problem. I’m not sure, why T5 sends this header.
>
> HTTP/1.1 200 OK
> Server: nginx/1.6.2
> Date: Tue, 10 May 2016 15:00:29 GMT
> Content-Type: text/javascript;charset=utf-8
> Content-Length: 429335
> Connection: keep-alive
> Expires: Sun, 19 Apr 2026 10:13:43 GMT
> Cache-Control: no-cache, no-store, must-revalidate
> Pragma: no-cache
> ETag: "2f0c65b4"
> Last-Modified: Thu, 21 Apr 2016 10:13:43 GMT
>
> Thanks and best,
> Thilo
>
>
> Von: Cezary Biernacki <ce...@gmail.com>
> Antworten an: Tapestry users <us...@tapestry.apache.org>
> Datum: Dienstag, 10. Mai 2016 16:05
> An: Tapestry users <us...@tapestry.apache.org>
> Betreff: Re: Asset Browser Caching
>
>
> Hi,
> what Tapestry version are you talking about? In my experience Tapestry is
> pretty good at enabling caching assets, with usage of ETags, expiry dates
> set for 10 years in the future, and custom URLs to assets. Can you post
> examples of the response headers from your Tapestry that prevent caching?
> Maybe your custom AssetRequestHandler somehow messes with headers.
>
> It is a bit different for modules, as they do not include checksum in the
> path, so they rely on ETags for verification, which makes browser to issue
> requests every 60 minutes, though hopefully Tapestry should avoid sending
> whole module again, just inform the browser that it does not changed.
>
> Best regards,
> Cezary
>
>
> On Tue, May 10, 2016 at 3:17 PM, Thilo Tanner <th...@reprisk.com>
> wrote:
>
> > Hi all,
> >
> > We use Tapestry mainly for internal applications. We have users working
> > from places with very limited bandwidth (use Chrome’s „Good 2G“ network
> > throttling to get an idea). It seems, the headers sent by Tapestry
> prevent
> > the browser from caching assets. I modified
> > OMIT_EXPIRATION_CACHE_CONTROL_HEADER, but without success (it seems, this
> > settings is only used for assets without a checksum path). Production
> mode
> > is enabled. I couldn’t find an issue in JIRA related to this problem, so
> > maybe we’re doing something wrong here. We use a modified
> > AssetRequestHandler to stream webjar assets from T5 submodules, but the
> > problem is the same for core.js or any other directly loaded asset.
> >
> > All inputs are welcome!
> >
> > Thanks and best,
> > Thilo
> >
> >
> > Thilo Tanner
> > Technology Lead
> >
> > Direct +41 43 300 54 42 <tel:+41%2043%20300%2054%2042>
> > Mobile +41 795064636 <tel:+41%20795064636>
> > thilo.tanner@reprisk.com <ma...@reprisk.com>
> > www.reprisk.com <https://www.reprisk.com>
> >
> > RepRisk AG
> > Stampfenbachstrasse 42, 8006 Zürich, Switzerland
> > Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <
> > https://www.reprisk.com>
> >
>
>
>
> Thilo Tanner
> Technology Lead
>
> Direct +41 43 300 54 42 <tel:+41 43 300 54 42>
> Mobile +41 795064636 <tel:+41 795064636>
> thilo.tanner@reprisk.com <ma...@reprisk.com>
> www.reprisk.com <https://www.reprisk.com>
>
> RepRisk AG
> Stampfenbachstrasse 42, 8006 Zürich, Switzerland
> Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <
> https://www.reprisk.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Thilo Tanner
Technology Lead
Direct +41 43 300 54 42 <tel:+41 43 300 54 42>
Mobile +41 795064636 <tel:+41 795064636>
thilo.tanner@reprisk.com <ma...@reprisk.com>
www.reprisk.com <https://www.reprisk.com>
RepRisk AG
Stampfenbachstrasse 42, 8006 Zürich, Switzerland
Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <https://www.reprisk.com>
Re: Asset Browser Caching
Posted by Cezary Biernacki <ce...@gmail.com>.
Tapestry 5.4 itself never sets "Pragma" header (except Kaptcha component,
but it must be included separately and it is set only for actual CAPTCHA
images), and never sets "Cache-Control" to "no-cache, no-store,
must-revalidate" by default, though this particular header could be via
"tapestry.omit-expiration-cache-control-header" option. I recommend first
again ensuring that your NGINX proxy is not accidentally configured to add
these headers, e.g. by observing response headers directly from Java
application. Once you confirm that it is not added by the proxy, check your
own application for any custom filters/dispatchers. Or just grep all your
sources and configuration files (e.g. web.xml) for "no-cache" text. My bet
is that somebody developing or maintaining your application one day had a
problem "the page does not refresh", and solved it by adding these headers
to all responses.
Best regards,
Cezary
On Tue, May 10, 2016 at 5:10 PM, Thilo Tanner <th...@reprisk.com>
wrote:
> Hi Cezary,
>
> Thanks a lot for your feedback.
>
> In production, we currently use 5.4-beta-26. I quickly tried 5.4.1
> yesterday, but the problem stays the same. Below the headers sent by our
> application for core.js for example (proxied through nginx, but the headers
> are the same locally). Etag looks good, Expires as well (not sure if
> current browsers like 10 years). To me, the Cache-Control header is the
> problem. I’m not sure, why T5 sends this header.
>
> HTTP/1.1 200 OK
> Server: nginx/1.6.2
> Date: Tue, 10 May 2016 15:00:29 GMT
> Content-Type: text/javascript;charset=utf-8
> Content-Length: 429335
> Connection: keep-alive
> Expires: Sun, 19 Apr 2026 10:13:43 GMT
> Cache-Control: no-cache, no-store, must-revalidate
> Pragma: no-cache
> ETag: "2f0c65b4"
> Last-Modified: Thu, 21 Apr 2016 10:13:43 GMT
>
> Thanks and best,
> Thilo
>
>
> Von: Cezary Biernacki <ce...@gmail.com>
> Antworten an: Tapestry users <us...@tapestry.apache.org>
> Datum: Dienstag, 10. Mai 2016 16:05
> An: Tapestry users <us...@tapestry.apache.org>
> Betreff: Re: Asset Browser Caching
>
>
> Hi,
> what Tapestry version are you talking about? In my experience Tapestry is
> pretty good at enabling caching assets, with usage of ETags, expiry dates
> set for 10 years in the future, and custom URLs to assets. Can you post
> examples of the response headers from your Tapestry that prevent caching?
> Maybe your custom AssetRequestHandler somehow messes with headers.
>
> It is a bit different for modules, as they do not include checksum in the
> path, so they rely on ETags for verification, which makes browser to issue
> requests every 60 minutes, though hopefully Tapestry should avoid sending
> whole module again, just inform the browser that it does not changed.
>
> Best regards,
> Cezary
>
>
> On Tue, May 10, 2016 at 3:17 PM, Thilo Tanner <th...@reprisk.com>
> wrote:
>
> > Hi all,
> >
> > We use Tapestry mainly for internal applications. We have users working
> > from places with very limited bandwidth (use Chrome’s „Good 2G“ network
> > throttling to get an idea). It seems, the headers sent by Tapestry
> prevent
> > the browser from caching assets. I modified
> > OMIT_EXPIRATION_CACHE_CONTROL_HEADER, but without success (it seems, this
> > settings is only used for assets without a checksum path). Production
> mode
> > is enabled. I couldn’t find an issue in JIRA related to this problem, so
> > maybe we’re doing something wrong here. We use a modified
> > AssetRequestHandler to stream webjar assets from T5 submodules, but the
> > problem is the same for core.js or any other directly loaded asset.
> >
> > All inputs are welcome!
> >
> > Thanks and best,
> > Thilo
> >
> >
> > Thilo Tanner
> > Technology Lead
> >
> > Direct +41 43 300 54 42 <tel:+41%2043%20300%2054%2042>
> > Mobile +41 795064636 <tel:+41%20795064636>
> > thilo.tanner@reprisk.com <ma...@reprisk.com>
> > www.reprisk.com <https://www.reprisk.com>
> >
> > RepRisk AG
> > Stampfenbachstrasse 42, 8006 Zürich, Switzerland
> > Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <
> > https://www.reprisk.com>
> >
>
>
>
> Thilo Tanner
> Technology Lead
>
> Direct +41 43 300 54 42 <tel:+41 43 300 54 42>
> Mobile +41 795064636 <tel:+41 795064636>
> thilo.tanner@reprisk.com <ma...@reprisk.com>
> www.reprisk.com <https://www.reprisk.com>
>
> RepRisk AG
> Stampfenbachstrasse 42, 8006 Zürich, Switzerland
> Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <
> https://www.reprisk.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: Asset Browser Caching
Posted by Thilo Tanner <th...@reprisk.com>.
Hi Cezary,
Thanks a lot for your feedback.
In production, we currently use 5.4-beta-26. I quickly tried 5.4.1 yesterday, but the problem stays the same. Below the headers sent by our application for core.js for example (proxied through nginx, but the headers are the same locally). Etag looks good, Expires as well (not sure if current browsers like 10 years). To me, the Cache-Control header is the problem. I’m not sure, why T5 sends this header.
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Tue, 10 May 2016 15:00:29 GMT
Content-Type: text/javascript;charset=utf-8
Content-Length: 429335
Connection: keep-alive
Expires: Sun, 19 Apr 2026 10:13:43 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
ETag: "2f0c65b4"
Last-Modified: Thu, 21 Apr 2016 10:13:43 GMT
Thanks and best,
Thilo
Von: Cezary Biernacki <ce...@gmail.com>
Antworten an: Tapestry users <us...@tapestry.apache.org>
Datum: Dienstag, 10. Mai 2016 16:05
An: Tapestry users <us...@tapestry.apache.org>
Betreff: Re: Asset Browser Caching
Hi,
what Tapestry version are you talking about? In my experience Tapestry is
pretty good at enabling caching assets, with usage of ETags, expiry dates
set for 10 years in the future, and custom URLs to assets. Can you post
examples of the response headers from your Tapestry that prevent caching?
Maybe your custom AssetRequestHandler somehow messes with headers.
It is a bit different for modules, as they do not include checksum in the
path, so they rely on ETags for verification, which makes browser to issue
requests every 60 minutes, though hopefully Tapestry should avoid sending
whole module again, just inform the browser that it does not changed.
Best regards,
Cezary
On Tue, May 10, 2016 at 3:17 PM, Thilo Tanner <th...@reprisk.com>
wrote:
> Hi all,
>
> We use Tapestry mainly for internal applications. We have users working
> from places with very limited bandwidth (use Chrome’s „Good 2G“ network
> throttling to get an idea). It seems, the headers sent by Tapestry prevent
> the browser from caching assets. I modified
> OMIT_EXPIRATION_CACHE_CONTROL_HEADER, but without success (it seems, this
> settings is only used for assets without a checksum path). Production mode
> is enabled. I couldn’t find an issue in JIRA related to this problem, so
> maybe we’re doing something wrong here. We use a modified
> AssetRequestHandler to stream webjar assets from T5 submodules, but the
> problem is the same for core.js or any other directly loaded asset.
>
> All inputs are welcome!
>
> Thanks and best,
> Thilo
>
>
> Thilo Tanner
> Technology Lead
>
> Direct +41 43 300 54 42 <tel:+41%2043%20300%2054%2042>
> Mobile +41 795064636 <tel:+41%20795064636>
> thilo.tanner@reprisk.com <ma...@reprisk.com>
> www.reprisk.com <https://www.reprisk.com>
>
> RepRisk AG
> Stampfenbachstrasse 42, 8006 Zürich, Switzerland
> Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <
> https://www.reprisk.com>
>
Thilo Tanner
Technology Lead
Direct +41 43 300 54 42 <tel:+41 43 300 54 42>
Mobile +41 795064636 <tel:+41 795064636>
thilo.tanner@reprisk.com <ma...@reprisk.com>
www.reprisk.com <https://www.reprisk.com>
RepRisk AG
Stampfenbachstrasse 42, 8006 Zürich, Switzerland
Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <https://www.reprisk.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Asset Browser Caching
Posted by Cezary Biernacki <ce...@gmail.com>.
Hi,
what Tapestry version are you talking about? In my experience Tapestry is
pretty good at enabling caching assets, with usage of ETags, expiry dates
set for 10 years in the future, and custom URLs to assets. Can you post
examples of the response headers from your Tapestry that prevent caching?
Maybe your custom AssetRequestHandler somehow messes with headers.
It is a bit different for modules, as they do not include checksum in the
path, so they rely on ETags for verification, which makes browser to issue
requests every 60 minutes, though hopefully Tapestry should avoid sending
whole module again, just inform the browser that it does not changed.
Best regards,
Cezary
On Tue, May 10, 2016 at 3:17 PM, Thilo Tanner <th...@reprisk.com>
wrote:
> Hi all,
>
> We use Tapestry mainly for internal applications. We have users working
> from places with very limited bandwidth (use Chrome’s „Good 2G“ network
> throttling to get an idea). It seems, the headers sent by Tapestry prevent
> the browser from caching assets. I modified
> OMIT_EXPIRATION_CACHE_CONTROL_HEADER, but without success (it seems, this
> settings is only used for assets without a checksum path). Production mode
> is enabled. I couldn’t find an issue in JIRA related to this problem, so
> maybe we’re doing something wrong here. We use a modified
> AssetRequestHandler to stream webjar assets from T5 submodules, but the
> problem is the same for core.js or any other directly loaded asset.
>
> All inputs are welcome!
>
> Thanks and best,
> Thilo
>
>
> Thilo Tanner
> Technology Lead
>
> Direct +41 43 300 54 42 <tel:+41%2043%20300%2054%2042>
> Mobile +41 795064636 <tel:+41%20795064636>
> thilo.tanner@reprisk.com <ma...@reprisk.com>
> www.reprisk.com <https://www.reprisk.com>
>
> RepRisk AG
> Stampfenbachstrasse 42, 8006 Zürich, Switzerland
> Office +41 43 300 54 40 Fax +41 43 300 54 46 [RepRisk Logo] <
> https://www.reprisk.com>
>