You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Harry Zhou <su...@gmail.com> on 2014/12/21 17:54:04 UTC
Far Future Expiration Headers of 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." So I am
not sure why responses for my assets all come with
"Cache-Control:no-cache" and "Pragma:no-cache".
Any help would be appreciated. Thanks!
Best Regards
Harry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by Chris Poulsen <ma...@nesluop.dk>.
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, Dec 22, 2014 at 6:44 PM, George Christman <gc...@cardaddy.com>
wrote:
> 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, so I'm not sure what the
> cause could be. I'll have to check the cdn, but this is what google is
> complaining about. The images are being called from a sprite map in
> css where the context binding prefix can't be used.
>
> Leverage browser caching
>
> Setting an expiry date or a maximum age in the HTTP headers for static
> resources instructs the browser to load previously downloaded
> resources from local disk rather than over the network.
> Leverage browser caching for the following cacheable resources:
>
> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
> not specified)
> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>
> Any thoughts?
>
> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com> wrote:
> > 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 cache").
> >
> > Google seems to take the position that "Expires" response headers are
> > "superseded." While Chrome honors "Expires" during browsing, it will
> > also look for a "Cache-Control" in response headers. See
> >
> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
> >
> >
> > On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
> > <th...@gmail.com> wrote:
> >> Another thing to check: production mode is off?
> >>
> >>
> >> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only
> when
> >>> running on a server?
> >>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
> >>>
> >>>> 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." So I am
> >>>> not sure why responses for my assets all come with
> >>>> "Cache-Control:no-cache" and "Pragma:no-cache".
> >>>>
> >>>> Any help would be appreciated. Thanks!
> >>>>
> >>>> Best Regards
> >>>> Harry
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>
> >>
> >> --
> >> Thiago H. de Paula Figueiredo
> >> Tapestry, Java and Hibernate consultant and developer
> >> http://machina.com.br
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> >
> > --
> > Best Regards
> > Harry Zhou
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Far Future Expiration Headers of Assets
Posted by George Christman <gc...@cardaddy.com>.
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 on the modules, it would also make it easy
for us to keep track of what library version we are running too. The
downside might just be the library maintenance during upgrades.
I'm only pushing on this topic do to the fact a websites speed is one
of the few known ranking factors of Google's algorithm. A website that
scores high for speed will move up the page rank as Google believes
the users will have a much better experience. Currently Google's
scoring tool is scoring me in the low 70's for mobile which is
primarily do to browser caching and render blocking css and js which
we spoke about this before for future releases. I also think if we get
this figured out it would help to reduce some of the hosting cost
associated with the cloud.
On Tue, Jan 27, 2015 at 3:10 PM, George Christman
<gc...@cardaddy.com> wrote:
> 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 knowledge on the proper way to handle
> expiration for asset headers, I ended up setting the expiration date
> for 1 year within apache httpd with the assumption the checksum would
> change.
>
> So as of right now it just appears google is complaining about the
> modules short expiration date "90", I'm not familiar with etag, but
> would that help to resolve my issues.
>
> On Tue, Jan 27, 2015 at 1:56 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> 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 <hl...@gmail.com>
>> wrote:
>>
>>> 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 expires headers in development.
>>>
>>> The naming may be a bit wonky, but the Javadoc should explain the
>>> reasoning. Basically, this is the cache control header for when the
>>> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
>>> not passed, we get the far-future expires header.
>>>
>>>
>>> On Tue, Jan 27, 2015 at 6:41 AM, George Christman <gchristman@cardaddy.com
>>> > wrote:
>>>
>>>> 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 to the other
>>>> core css style sheets
>>>>
>>>> (no expires)
>>>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
>>>> (no expires)
>>>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
>>>> (no expires)
>>>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
>>>> (no expires)
>>>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>>>>
>>>> Any thoughts?
>>>>
>>>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
>>>> <gc...@cardaddy.com> wrote:
>>>> > 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 <su...@gmail.com>
>>>> wrote:
>>>> >> 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 are indeed cached
>>>> >> after the initial round of full requests ("200 from cache" will be
>>>> >> shown for cached assets). No requests for these assets will actually
>>>> >> be sent to server unless the user clicks the refresh button or run an
>>>> >> audit with page reload from Chrome PageSpeed. The latter case is
>>>> >> where PageSpeed will complain about the assets, because although it
>>>> >> sees the 10-year-in-the-future headers in the responses, which Chrome
>>>> >> does honor and will cache accordingly, PageSpeed will, however, want
>>>> >> to see a "Cache-Control" header in responses. It is likely a
>>>> >> non-issue because during ordinary browsing client caching is
>>>> >> leveraged.
>>>> >>
>>>> >> The 60 seconds for modules are discussed here:
>>>> >> http://tapestry.apache.org/javascript-modules.html
>>>> >>
>>>> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>>>> >> you won't see module requests on every page load. This is configurable
>>>> >> and you may want a much higher value in production. If you are rapidly
>>>> >> iterating on the source of a module, you may need to force the browser
>>>> >> to reload after clearing local cache. Chrome has an option to disable
>>>> >> the client-side cache when its developer tools are open."
>>>> >>
>>>> >> The page lists solutions as well.
>>>> >>
>>>> >> Harry
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
>>>> >> <gc...@cardaddy.com> wrote:
>>>> >>> 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, so I'm not sure what the
>>>> >>> cause could be. I'll have to check the cdn, but this is what google is
>>>> >>> complaining about. The images are being called from a sprite map in
>>>> >>> css where the context binding prefix can't be used.
>>>> >>>
>>>> >>> Leverage browser caching
>>>> >>>
>>>> >>> Setting an expiry date or a maximum age in the HTTP headers for static
>>>> >>> resources instructs the browser to load previously downloaded
>>>> >>> resources from local disk rather than over the network.
>>>> >>> Leverage browser caching for the following cacheable resources:
>>>> >>>
>>>> >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg
>>>> (expiration
>>>> >>> not specified)
>>>> >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg
>>>> (expiration
>>>> >>> not specified)
>>>> >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg
>>>> (expiration
>>>> >>> not specified)
>>>> >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg
>>>> (expiration
>>>> >>> not specified)
>>>> >>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60
>>>> seconds)
>>>> >>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60
>>>> seconds)
>>>> >>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60
>>>> seconds)
>>>> >>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60
>>>> seconds)
>>>> >>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60
>>>> seconds)
>>>> >>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>>>> >>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>>>> >>>
>>>> >>> Any thoughts?
>>>> >>>
>>>> >>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com>
>>>> wrote:
>>>> >>>> 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 cache").
>>>> >>>>
>>>> >>>> Google seems to take the position that "Expires" response headers are
>>>> >>>> "superseded." While Chrome honors "Expires" during browsing, it will
>>>> >>>> also look for a "Cache-Control" in response headers. See
>>>> >>>>
>>>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>>> >>>>
>>>> >>>>
>>>> >>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>>>> >>>> <th...@gmail.com> wrote:
>>>> >>>>> Another thing to check: production mode is off?
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or
>>>> only when
>>>> >>>>>> running on a server?
>>>> >>>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com>
>>>> wrote:
>>>> >>>>>>
>>>> >>>>>>> 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." So
>>>> I am
>>>> >>>>>>> not sure why responses for my assets all come with
>>>> >>>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>>> >>>>>>>
>>>> >>>>>>> Any help would be appreciated. Thanks!
>>>> >>>>>>>
>>>> >>>>>>> Best Regards
>>>> >>>>>>> Harry
>>>> >>>>>>>
>>>> >>>>>>>
>>>> ---------------------------------------------------------------------
>>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> Thiago H. de Paula Figueiredo
>>>> >>>>> Tapestry, Java and Hibernate consultant and developer
>>>> >>>>> http://machina.com.br
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> ---------------------------------------------------------------------
>>>> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Best Regards
>>>> >>>> Harry Zhou
>>>> >>>>
>>>> >>>> ---------------------------------------------------------------------
>>>> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> George Christman
>>>> >>> CEO
>>>> >>> www.CarDaddy.com
>>>> >>> P.O. Box 735
>>>> >>> Johnstown, New York
>>>> >>>
>>>> >>> ---------------------------------------------------------------------
>>>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Best Regards
>>>> >> Harry Zhou
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > George Christman
>>>> > CEO
>>>> > www.CarDaddy.com
>>>> > P.O. Box 735
>>>> > Johnstown, New York
>>>>
>>>>
>>>>
>>>> --
>>>> George Christman
>>>> CEO
>>>> www.CarDaddy.com
>>>> P.O. Box 735
>>>> Johnstown, New York
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>> @hlship
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by George Christman <gc...@cardaddy.com>.
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 knowledge on the proper way to handle
expiration for asset headers, I ended up setting the expiration date
for 1 year within apache httpd with the assumption the checksum would
change.
So as of right now it just appears google is complaining about the
modules short expiration date "90", I'm not familiar with etag, but
would that help to resolve my issues.
On Tue, Jan 27, 2015 at 1:56 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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 <hl...@gmail.com>
> wrote:
>
>> 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 expires headers in development.
>>
>> The naming may be a bit wonky, but the Javadoc should explain the
>> reasoning. Basically, this is the cache control header for when the
>> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
>> not passed, we get the far-future expires header.
>>
>>
>> On Tue, Jan 27, 2015 at 6:41 AM, George Christman <gchristman@cardaddy.com
>> > wrote:
>>
>>> 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 to the other
>>> core css style sheets
>>>
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>>>
>>> Any thoughts?
>>>
>>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
>>> <gc...@cardaddy.com> wrote:
>>> > 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 <su...@gmail.com>
>>> wrote:
>>> >> 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 are indeed cached
>>> >> after the initial round of full requests ("200 from cache" will be
>>> >> shown for cached assets). No requests for these assets will actually
>>> >> be sent to server unless the user clicks the refresh button or run an
>>> >> audit with page reload from Chrome PageSpeed. The latter case is
>>> >> where PageSpeed will complain about the assets, because although it
>>> >> sees the 10-year-in-the-future headers in the responses, which Chrome
>>> >> does honor and will cache accordingly, PageSpeed will, however, want
>>> >> to see a "Cache-Control" header in responses. It is likely a
>>> >> non-issue because during ordinary browsing client caching is
>>> >> leveraged.
>>> >>
>>> >> The 60 seconds for modules are discussed here:
>>> >> http://tapestry.apache.org/javascript-modules.html
>>> >>
>>> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>>> >> you won't see module requests on every page load. This is configurable
>>> >> and you may want a much higher value in production. If you are rapidly
>>> >> iterating on the source of a module, you may need to force the browser
>>> >> to reload after clearing local cache. Chrome has an option to disable
>>> >> the client-side cache when its developer tools are open."
>>> >>
>>> >> The page lists solutions as well.
>>> >>
>>> >> Harry
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
>>> >> <gc...@cardaddy.com> wrote:
>>> >>> 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, so I'm not sure what the
>>> >>> cause could be. I'll have to check the cdn, but this is what google is
>>> >>> complaining about. The images are being called from a sprite map in
>>> >>> css where the context binding prefix can't be used.
>>> >>>
>>> >>> Leverage browser caching
>>> >>>
>>> >>> Setting an expiry date or a maximum age in the HTTP headers for static
>>> >>> resources instructs the browser to load previously downloaded
>>> >>> resources from local disk rather than over the network.
>>> >>> Leverage browser caching for the following cacheable resources:
>>> >>>
>>> >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg
>>> (expiration
>>> >>> not specified)
>>> >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg
>>> (expiration
>>> >>> not specified)
>>> >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg
>>> (expiration
>>> >>> not specified)
>>> >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg
>>> (expiration
>>> >>> not specified)
>>> >>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60
>>> seconds)
>>> >>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60
>>> seconds)
>>> >>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60
>>> seconds)
>>> >>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60
>>> seconds)
>>> >>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60
>>> seconds)
>>> >>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>>> >>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>>> >>>
>>> >>> Any thoughts?
>>> >>>
>>> >>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com>
>>> wrote:
>>> >>>> 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 cache").
>>> >>>>
>>> >>>> Google seems to take the position that "Expires" response headers are
>>> >>>> "superseded." While Chrome honors "Expires" during browsing, it will
>>> >>>> also look for a "Cache-Control" in response headers. See
>>> >>>>
>>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>> >>>>
>>> >>>>
>>> >>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>>> >>>> <th...@gmail.com> wrote:
>>> >>>>> Another thing to check: production mode is off?
>>> >>>>>
>>> >>>>>
>>> >>>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or
>>> only when
>>> >>>>>> running on a server?
>>> >>>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com>
>>> wrote:
>>> >>>>>>
>>> >>>>>>> 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." So
>>> I am
>>> >>>>>>> not sure why responses for my assets all come with
>>> >>>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>> >>>>>>>
>>> >>>>>>> Any help would be appreciated. Thanks!
>>> >>>>>>>
>>> >>>>>>> Best Regards
>>> >>>>>>> Harry
>>> >>>>>>>
>>> >>>>>>>
>>> ---------------------------------------------------------------------
>>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Thiago H. de Paula Figueiredo
>>> >>>>> Tapestry, Java and Hibernate consultant and developer
>>> >>>>> http://machina.com.br
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Best Regards
>>> >>>> Harry Zhou
>>> >>>>
>>> >>>> ---------------------------------------------------------------------
>>> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> George Christman
>>> >>> CEO
>>> >>> www.CarDaddy.com
>>> >>> P.O. Box 735
>>> >>> Johnstown, New York
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Best Regards
>>> >> Harry Zhou
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > George Christman
>>> > CEO
>>> > www.CarDaddy.com
>>> > P.O. Box 735
>>> > Johnstown, New York
>>>
>>>
>>>
>>> --
>>> George Christman
>>> CEO
>>> www.CarDaddy.com
>>> P.O. Box 735
>>> Johnstown, New York
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>> @hlship
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <hl...@gmail.com>
wrote:
> 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 expires headers in development.
>
> The naming may be a bit wonky, but the Javadoc should explain the
> reasoning. Basically, this is the cache control header for when the
> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
> not passed, we get the far-future expires header.
>
>
> On Tue, Jan 27, 2015 at 6:41 AM, George Christman <gchristman@cardaddy.com
> > wrote:
>
>> 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 to the other
>> core css style sheets
>>
>> (no expires)
>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
>> (no expires)
>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
>> (no expires)
>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
>> (no expires)
>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>>
>> Any thoughts?
>>
>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
>> <gc...@cardaddy.com> wrote:
>> > 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 <su...@gmail.com>
>> wrote:
>> >> 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 are indeed cached
>> >> after the initial round of full requests ("200 from cache" will be
>> >> shown for cached assets). No requests for these assets will actually
>> >> be sent to server unless the user clicks the refresh button or run an
>> >> audit with page reload from Chrome PageSpeed. The latter case is
>> >> where PageSpeed will complain about the assets, because although it
>> >> sees the 10-year-in-the-future headers in the responses, which Chrome
>> >> does honor and will cache accordingly, PageSpeed will, however, want
>> >> to see a "Cache-Control" header in responses. It is likely a
>> >> non-issue because during ordinary browsing client caching is
>> >> leveraged.
>> >>
>> >> The 60 seconds for modules are discussed here:
>> >> http://tapestry.apache.org/javascript-modules.html
>> >>
>> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>> >> you won't see module requests on every page load. This is configurable
>> >> and you may want a much higher value in production. If you are rapidly
>> >> iterating on the source of a module, you may need to force the browser
>> >> to reload after clearing local cache. Chrome has an option to disable
>> >> the client-side cache when its developer tools are open."
>> >>
>> >> The page lists solutions as well.
>> >>
>> >> Harry
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
>> >> <gc...@cardaddy.com> wrote:
>> >>> 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, so I'm not sure what the
>> >>> cause could be. I'll have to check the cdn, but this is what google is
>> >>> complaining about. The images are being called from a sprite map in
>> >>> css where the context binding prefix can't be used.
>> >>>
>> >>> Leverage browser caching
>> >>>
>> >>> Setting an expiry date or a maximum age in the HTTP headers for static
>> >>> resources instructs the browser to load previously downloaded
>> >>> resources from local disk rather than over the network.
>> >>> Leverage browser caching for the following cacheable resources:
>> >>>
>> >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg
>> (expiration
>> >>> not specified)
>> >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg
>> (expiration
>> >>> not specified)
>> >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg
>> (expiration
>> >>> not specified)
>> >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg
>> (expiration
>> >>> not specified)
>> >>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60
>> seconds)
>> >>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60
>> seconds)
>> >>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60
>> seconds)
>> >>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60
>> seconds)
>> >>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60
>> seconds)
>> >>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>> >>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>> >>>
>> >>> Any thoughts?
>> >>>
>> >>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com>
>> wrote:
>> >>>> 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 cache").
>> >>>>
>> >>>> Google seems to take the position that "Expires" response headers are
>> >>>> "superseded." While Chrome honors "Expires" during browsing, it will
>> >>>> also look for a "Cache-Control" in response headers. See
>> >>>>
>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>> >>>>
>> >>>>
>> >>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>> >>>> <th...@gmail.com> wrote:
>> >>>>> Another thing to check: production mode is off?
>> >>>>>
>> >>>>>
>> >>>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or
>> only when
>> >>>>>> running on a server?
>> >>>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com>
>> wrote:
>> >>>>>>
>> >>>>>>> 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." So
>> I am
>> >>>>>>> not sure why responses for my assets all come with
>> >>>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>> >>>>>>>
>> >>>>>>> Any help would be appreciated. Thanks!
>> >>>>>>>
>> >>>>>>> Best Regards
>> >>>>>>> Harry
>> >>>>>>>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Thiago H. de Paula Figueiredo
>> >>>>> Tapestry, Java and Hibernate consultant and developer
>> >>>>> http://machina.com.br
>> >>>>>
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Best Regards
>> >>>> Harry Zhou
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> George Christman
>> >>> CEO
>> >>> www.CarDaddy.com
>> >>> P.O. Box 735
>> >>> Johnstown, New York
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Best Regards
>> >> Harry Zhou
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > George Christman
>> > CEO
>> > www.CarDaddy.com
>> > P.O. Box 735
>> > Johnstown, New York
>>
>>
>>
>> --
>> George Christman
>> CEO
>> www.CarDaddy.com
>> P.O. Box 735
>> Johnstown, New York
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
@hlship
Re: Far Future Expiration Headers of Assets
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 expires headers in development.
The naming may be a bit wonky, but the Javadoc should explain the
reasoning. Basically, this is the cache control header for when the
OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
not passed, we get the far-future expires header.
On Tue, Jan 27, 2015 at 6:41 AM, George Christman <gc...@cardaddy.com>
wrote:
> 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 to the other
> core css style sheets
>
> (no expires)
> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
> (no expires)
> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
> (no expires)
> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
> (no expires)
> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>
> Any thoughts?
>
> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
> <gc...@cardaddy.com> wrote:
> > 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 <su...@gmail.com>
> wrote:
> >> 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 are indeed cached
> >> after the initial round of full requests ("200 from cache" will be
> >> shown for cached assets). No requests for these assets will actually
> >> be sent to server unless the user clicks the refresh button or run an
> >> audit with page reload from Chrome PageSpeed. The latter case is
> >> where PageSpeed will complain about the assets, because although it
> >> sees the 10-year-in-the-future headers in the responses, which Chrome
> >> does honor and will cache accordingly, PageSpeed will, however, want
> >> to see a "Cache-Control" header in responses. It is likely a
> >> non-issue because during ordinary browsing client caching is
> >> leveraged.
> >>
> >> The 60 seconds for modules are discussed here:
> >> http://tapestry.apache.org/javascript-modules.html
> >>
> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
> >> you won't see module requests on every page load. This is configurable
> >> and you may want a much higher value in production. If you are rapidly
> >> iterating on the source of a module, you may need to force the browser
> >> to reload after clearing local cache. Chrome has an option to disable
> >> the client-side cache when its developer tools are open."
> >>
> >> The page lists solutions as well.
> >>
> >> Harry
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
> >> <gc...@cardaddy.com> wrote:
> >>> 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, so I'm not sure what the
> >>> cause could be. I'll have to check the cdn, but this is what google is
> >>> complaining about. The images are being called from a sprite map in
> >>> css where the context binding prefix can't be used.
> >>>
> >>> Leverage browser caching
> >>>
> >>> Setting an expiry date or a maximum age in the HTTP headers for static
> >>> resources instructs the browser to load previously downloaded
> >>> resources from local disk rather than over the network.
> >>> Leverage browser caching for the following cacheable resources:
> >>>
> >>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
> >>> not specified)
> >>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
> >>> not specified)
> >>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
> >>> not specified)
> >>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
> >>> not specified)
> >>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60
> seconds)
> >>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
> >>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
> >>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60
> seconds)
> >>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60
> seconds)
> >>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
> >>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
> >>>
> >>> Any thoughts?
> >>>
> >>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com>
> wrote:
> >>>> 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 cache").
> >>>>
> >>>> Google seems to take the position that "Expires" response headers are
> >>>> "superseded." While Chrome honors "Expires" during browsing, it will
> >>>> also look for a "Cache-Control" in response headers. See
> >>>>
> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
> >>>>
> >>>>
> >>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
> >>>> <th...@gmail.com> wrote:
> >>>>> Another thing to check: production mode is off?
> >>>>>
> >>>>>
> >>>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or
> only when
> >>>>>> running on a server?
> >>>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> 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." So I
> am
> >>>>>>> not sure why responses for my assets all come with
> >>>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
> >>>>>>>
> >>>>>>> Any help would be appreciated. Thanks!
> >>>>>>>
> >>>>>>> Best Regards
> >>>>>>> Harry
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Thiago H. de Paula Figueiredo
> >>>>> Tapestry, Java and Hibernate consultant and developer
> >>>>> http://machina.com.br
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards
> >>>> Harry Zhou
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> George Christman
> >>> CEO
> >>> www.CarDaddy.com
> >>> P.O. Box 735
> >>> Johnstown, New York
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards
> >> Harry Zhou
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> >
> > --
> > George Christman
> > CEO
> > www.CarDaddy.com
> > P.O. Box 735
> > Johnstown, New York
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
@hlship
Re: Far Future Expiration Headers of Assets
Posted by George Christman <gc...@cardaddy.com>.
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 to the other
core css style sheets
(no expires) http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
(no expires) http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
(no expires) http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
(no expires) http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
Any thoughts?
On Tue, Jan 27, 2015 at 8:48 AM, George Christman
<gc...@cardaddy.com> wrote:
> 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 <su...@gmail.com> wrote:
>> 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 are indeed cached
>> after the initial round of full requests ("200 from cache" will be
>> shown for cached assets). No requests for these assets will actually
>> be sent to server unless the user clicks the refresh button or run an
>> audit with page reload from Chrome PageSpeed. The latter case is
>> where PageSpeed will complain about the assets, because although it
>> sees the 10-year-in-the-future headers in the responses, which Chrome
>> does honor and will cache accordingly, PageSpeed will, however, want
>> to see a "Cache-Control" header in responses. It is likely a
>> non-issue because during ordinary browsing client caching is
>> leveraged.
>>
>> The 60 seconds for modules are discussed here:
>> http://tapestry.apache.org/javascript-modules.html
>>
>> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>> you won't see module requests on every page load. This is configurable
>> and you may want a much higher value in production. If you are rapidly
>> iterating on the source of a module, you may need to force the browser
>> to reload after clearing local cache. Chrome has an option to disable
>> the client-side cache when its developer tools are open."
>>
>> The page lists solutions as well.
>>
>> Harry
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
>> <gc...@cardaddy.com> wrote:
>>> 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, so I'm not sure what the
>>> cause could be. I'll have to check the cdn, but this is what google is
>>> complaining about. The images are being called from a sprite map in
>>> css where the context binding prefix can't be used.
>>>
>>> Leverage browser caching
>>>
>>> Setting an expiry date or a maximum age in the HTTP headers for static
>>> resources instructs the browser to load previously downloaded
>>> resources from local disk rather than over the network.
>>> Leverage browser caching for the following cacheable resources:
>>>
>>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
>>> not specified)
>>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
>>> not specified)
>>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
>>> not specified)
>>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
>>> not specified)
>>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>>>
>>> Any thoughts?
>>>
>>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com> wrote:
>>>> 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 cache").
>>>>
>>>> Google seems to take the position that "Expires" response headers are
>>>> "superseded." While Chrome honors "Expires" during browsing, it will
>>>> also look for a "Cache-Control" in response headers. See
>>>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>>>
>>>>
>>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>>>> <th...@gmail.com> wrote:
>>>>> Another thing to check: production mode is off?
>>>>>
>>>>>
>>>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only when
>>>>>> running on a server?
>>>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
>>>>>>
>>>>>>> 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." So I am
>>>>>>> not sure why responses for my assets all come with
>>>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>>>>>>
>>>>>>> Any help would be appreciated. Thanks!
>>>>>>>
>>>>>>> Best Regards
>>>>>>> Harry
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thiago H. de Paula Figueiredo
>>>>> Tapestry, Java and Hibernate consultant and developer
>>>>> http://machina.com.br
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> Harry Zhou
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> George Christman
>>> CEO
>>> www.CarDaddy.com
>>> P.O. Box 735
>>> Johnstown, New York
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>>
>> --
>> Best Regards
>> Harry Zhou
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by George Christman <gc...@cardaddy.com>.
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 <su...@gmail.com> wrote:
> 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 are indeed cached
> after the initial round of full requests ("200 from cache" will be
> shown for cached assets). No requests for these assets will actually
> be sent to server unless the user clicks the refresh button or run an
> audit with page reload from Chrome PageSpeed. The latter case is
> where PageSpeed will complain about the assets, because although it
> sees the 10-year-in-the-future headers in the responses, which Chrome
> does honor and will cache accordingly, PageSpeed will, however, want
> to see a "Cache-Control" header in responses. It is likely a
> non-issue because during ordinary browsing client caching is
> leveraged.
>
> The 60 seconds for modules are discussed here:
> http://tapestry.apache.org/javascript-modules.html
>
> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
> you won't see module requests on every page load. This is configurable
> and you may want a much higher value in production. If you are rapidly
> iterating on the source of a module, you may need to force the browser
> to reload after clearing local cache. Chrome has an option to disable
> the client-side cache when its developer tools are open."
>
> The page lists solutions as well.
>
> Harry
>
>
>
>
>
>
>
> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
> <gc...@cardaddy.com> wrote:
>> 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, so I'm not sure what the
>> cause could be. I'll have to check the cdn, but this is what google is
>> complaining about. The images are being called from a sprite map in
>> css where the context binding prefix can't be used.
>>
>> Leverage browser caching
>>
>> Setting an expiry date or a maximum age in the HTTP headers for static
>> resources instructs the browser to load previously downloaded
>> resources from local disk rather than over the network.
>> Leverage browser caching for the following cacheable resources:
>>
>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
>> not specified)
>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
>> not specified)
>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
>> not specified)
>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
>> not specified)
>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>>
>> Any thoughts?
>>
>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com> wrote:
>>> 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 cache").
>>>
>>> Google seems to take the position that "Expires" response headers are
>>> "superseded." While Chrome honors "Expires" during browsing, it will
>>> also look for a "Cache-Control" in response headers. See
>>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>>
>>>
>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>>> <th...@gmail.com> wrote:
>>>> Another thing to check: production mode is off?
>>>>
>>>>
>>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only when
>>>>> running on a server?
>>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
>>>>>
>>>>>> 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." So I am
>>>>>> not sure why responses for my assets all come with
>>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>>>>>
>>>>>> Any help would be appreciated. Thanks!
>>>>>>
>>>>>> Best Regards
>>>>>> Harry
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Thiago H. de Paula Figueiredo
>>>> Tapestry, Java and Hibernate consultant and developer
>>>> http://machina.com.br
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Harry Zhou
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>>
>> --
>> George Christman
>> CEO
>> www.CarDaddy.com
>> P.O. Box 735
>> Johnstown, New York
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> --
> Best Regards
> Harry Zhou
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by Harry Zhou <su...@gmail.com>.
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 are indeed cached
after the initial round of full requests ("200 from cache" will be
shown for cached assets). No requests for these assets will actually
be sent to server unless the user clicks the refresh button or run an
audit with page reload from Chrome PageSpeed. The latter case is
where PageSpeed will complain about the assets, because although it
sees the 10-year-in-the-future headers in the responses, which Chrome
does honor and will cache accordingly, PageSpeed will, however, want
to see a "Cache-Control" header in responses. It is likely a
non-issue because during ordinary browsing client caching is
leveraged.
The 60 seconds for modules are discussed here:
http://tapestry.apache.org/javascript-modules.html
"By default, Tapestry sets a max age of 60 (seconds) on modules, so
you won't see module requests on every page load. This is configurable
and you may want a much higher value in production. If you are rapidly
iterating on the source of a module, you may need to force the browser
to reload after clearing local cache. Chrome has an option to disable
the client-side cache when its developer tools are open."
The page lists solutions as well.
Harry
On Mon, Dec 22, 2014 at 12:44 PM, George Christman
<gc...@cardaddy.com> wrote:
> 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, so I'm not sure what the
> cause could be. I'll have to check the cdn, but this is what google is
> complaining about. The images are being called from a sprite map in
> css where the context binding prefix can't be used.
>
> Leverage browser caching
>
> Setting an expiry date or a maximum age in the HTTP headers for static
> resources instructs the browser to load previously downloaded
> resources from local disk rather than over the network.
> Leverage browser caching for the following cacheable resources:
>
> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
> not specified)
> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>
> Any thoughts?
>
> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com> wrote:
>> 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 cache").
>>
>> Google seems to take the position that "Expires" response headers are
>> "superseded." While Chrome honors "Expires" during browsing, it will
>> also look for a "Cache-Control" in response headers. See
>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>
>>
>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>> Another thing to check: production mode is off?
>>>
>>>
>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only when
>>>> running on a server?
>>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
>>>>
>>>>> 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." So I am
>>>>> not sure why responses for my assets all come with
>>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>>>>
>>>>> Any help would be appreciated. Thanks!
>>>>>
>>>>> Best Regards
>>>>> Harry
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Tapestry, Java and Hibernate consultant and developer
>>> http://machina.com.br
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>>
>> --
>> Best Regards
>> Harry Zhou
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Best Regards
Harry Zhou
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by George Christman <gc...@cardaddy.com>.
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, so I'm not sure what the
cause could be. I'll have to check the cdn, but this is what google is
complaining about. The images are being called from a sprite map in
css where the context binding prefix can't be used.
Leverage browser caching
Setting an expiry date or a maximum age in the HTTP headers for static
resources instructs the browser to load previously downloaded
resources from local disk rather than over the network.
Leverage browser caching for the following cacheable resources:
https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
not specified)
https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
not specified)
https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
not specified)
https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
not specified)
https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
Any thoughts?
On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou <su...@gmail.com> wrote:
> 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 cache").
>
> Google seems to take the position that "Expires" response headers are
> "superseded." While Chrome honors "Expires" during browsing, it will
> also look for a "Cache-Control" in response headers. See
> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>
>
> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
> <th...@gmail.com> wrote:
>> Another thing to check: production mode is off?
>>
>>
>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only when
>>> running on a server?
>>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
>>>
>>>> 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." So I am
>>>> not sure why responses for my assets all come with
>>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>>>
>>>> Any help would be appreciated. Thanks!
>>>>
>>>> Best Regards
>>>> Harry
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> --
> Best Regards
> Harry Zhou
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by Harry Zhou <su...@gmail.com>.
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 cache").
Google seems to take the position that "Expires" response headers are
"superseded." While Chrome honors "Expires" during browsing, it will
also look for a "Cache-Control" in response headers. See
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
<th...@gmail.com> wrote:
> Another thing to check: production mode is off?
>
>
> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only when
>> running on a server?
>> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
>>
>>> 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." So I am
>>> not sure why responses for my assets all come with
>>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>>
>>> Any help would be appreciated. Thanks!
>>>
>>> Best Regards
>>> Harry
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Best Regards
Harry Zhou
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
Another thing to check: production mode is off?
On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner <bo...@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 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 issue happen on your desktop with local host, or only
> when
> running on a server?
> On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
>
>> 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." So I am
>> not sure why responses for my assets all come with
>> "Cache-Control:no-cache" and "Pragma:no-cache".
>>
>> Any help would be appreciated. Thanks!
>>
>> Best Regards
>> Harry
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Posted by Bob Harner <bo...@gmail.com>.
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 issue happen on your desktop with local host, or only when
running on a server?
On Dec 21, 2014 11:55 AM, "Harry Zhou" <su...@gmail.com> wrote:
> 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." So I am
> not sure why responses for my assets all come with
> "Cache-Control:no-cache" and "Pragma:no-cache".
>
> Any help would be appreciated. Thanks!
>
> Best Regards
> Harry
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>