[Building Sakai] http expiration

[Charles Hedrick]

I have it working in test. It involves modifying the few places that currently set expiration,and then adding the expire filter to tomcat/conf/web.xml

The only thing that bothers me is that whenever web.xml changes we now have to merge this change. I’m wondering whether we should also do it on the load balancer

On Aug 28, 2014, at 3:49 PM, Matthew Jones <matthew at longsight.com> wrote:

> Yeah, in Sakai we don't deliver very large javascript, and having a slight slowdown on the first hit of the day seems reasonable for better expiration. 24 hours is more than reasoanble for most pages. Basically the biggest impact is the ckeditor.js, MyInfusion.js and famfamfam.png, which together are about 1MB. Which is still instant on nearly all networks nowadays. 
> 
> I even was trying to think about the best way to refresh dynamic (json) data as that also is cached for too long and not updated. (https://jira.sakaiproject.org/browse/SAK-26347) This causes some things that seem like bugs, especially since we are moving more of the UI to be dynamic.
> 
> 
> On Thu, Aug 28, 2014 at 3:31 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
> That’s useful. If you’re doing it, tt tells us that 24 hours doesn’t cause unreasonable user behavior.
> 
> On Aug 28, 2014, at 3:16 PM, Sam Ottenhoff <ottenhoff at longsight.com> wrote:
> 
>> Sure, if you submit a patch, we can talk about a good default on the next Thursday Sakai Team call.
>> 
>> We do exactly what you describe (modify expires) on the front-end load-balancer level.  We use the Nginx expires rule to set a 24 hour expires header on all static JS/CSS assets.
>> 
>> --Sam
>> 
>> 
>> On Thu, Aug 28, 2014 at 3:07 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
>> library, portal and calendar use a filter to set max-age to a month. Other tools don’t do anything, which results in a random but long time.
>> 
>> Every time we update sakai we have a period of weeks when people’s results are broken because of our of data Javascript.
>> 
>> I think a month is too long. With modern browsers when the cache expires they just check. They won’t fetch the file if it hasn’t changed. I think a day makes more sense. Furthemore, it has to apply to .js files in the tools, not just library.
>> 
>> I propose using the tomcat or java expires filter to set a one-day expiration for all files of type javascript.
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140828/eae0d5a5/attachment.html