[Building Sakai] http expiration

[Charles Hedrick]

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"
> 

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