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 <cezary...@gmail.com> Antworten an: Tapestry users <users@tapestry.apache.org> Datum: Dienstag, 10. Mai 2016 16:05 An: Tapestry users <users@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 <thilo.tan...@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.tan...@reprisk.com <mailto:thilo.tan...@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.tan...@reprisk.com <mailto:thilo.tan...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
