Howard, just a thought. It appears as if the files with the 60 sec
cache are mostly Tapestry core files. Since we are unable to put a
checksum in the URI, would it be possible to put a version in the
filename? Example, bootstrap3.xx.css etc. I would think we could then
use a far future expiration
Hi Guys, I'm back on this topic again. Does anybody know how to bump
up the default 60 second time to something further in the future?
On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou superha...@gmail.com wrote:
Hi George,
It does sound like the same issue.
Regarding the leverage browser caching
Modules can't have a far-future expires header, because we can't put a
fingerprint (asset checksum) into a module URI.
All other assets have a checksum in the URI and get the far future expires
header.
The handling of this is different between development mode and production
mode. Short or no
In production mode Google / yslow have both been complaining about
assets missing expiration dates as well as the modules being too
short. You can see an example here.
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.cardaddy.com%2F
Now do to my lack of Tapestry
Further, for both modules and normal assets, there's etag support ... so
most requsts for a module get a 304 and the browser can use its local cache.
On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship hls...@gmail.com
wrote:
Modules can't have a far-future expires header, because we can't put
So I figured out how to change the 60sec,
configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER,
max-age=
2419200,must-revalidate);
OMIT_EXPIRATION is a bit misleading as I thought it meant to remove
the expiration dates.
Now I just need to figure out how to ad expiration dates
I'm having this same issue which I posted up a couple weeks ago
without any response.
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html
So my first question is what did you do to resolve the issue?
Secondly I am running in production mode,
The cdn should handle the expire headers. Tapestry only tells the client
where to get the files.
As for the modules I've never had a look at their expiration time, but a
simple test app in production mode also reposts 60secs here. - Guess that
could be something to dig into.
--
Chris
On Mon,
Hi George,
It does sound like the same issue.
Regarding the leverage browser caching warning, I did not solve
the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
if one keeps the Chrome developer panel up and click around in a
Tapestry webapp, one should see that the assets
Hi!
About my T5.4 site, Google is complaining that resources are missing
a cache expiration. Resources that do not specify an expiration may
not be cached by browsers . . .
I read that assets get a far-future expires header and will be
client browsers will aggressively cache downloaded assets.
Be sure production mode is on and that your links to the asset are using
the asset: or context: binding prefix.
Can you give us a typical asset URL (as seen by the browser)? That might
give us some hints.
Also be sure the expires headers aren't being removed by a proxy or CDN.
Hint: doest the
Another thing to check: production mode is off?
On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner bobhar...@gmail.com wrote:
Be sure production mode is on and that your links to the asset are using
the asset: or context: binding prefix.
Can you give us a typical asset URL (as seen by the
Hi Bob and Thiago, thank you for pointing me to the right direction!
Problem solved.
It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to
ignore Tapestry's 10-year-in-the-future Expires response header.
But during actual browsing the assets are actually cached (seeing 200
from
13 matches
Mail list logo
