None of this is applicable for closed intranet sites, and cache-control solves the very annoying situation where users are running an old version of CSS or Javascript.
I agree with these points for public facing ‘web sites’. For ‘enterprise SPAs’ there is usually a different context and set of requirements/restrictions to deal with. > On 19 Jun 2015, at 13:56, Fluid Dynamics <a2093...@trbvm.com> wrote: > > On Friday, June 19, 2015 at 5:54:03 AM UTC-4, James Reeves wrote: > Ring doesn't set any caching headers unless you add in middleware to do so. > > The most common middleware is wrap-not-modified, which returns a 304 response > if the etag or last-modified dates indicate the resource hasn't been > modified. For resources in jar files, the last-modified date is set to the > modification date of the containing jar. > > You could add some middleware to force the browser not to cache resources via > the cache-control header (see here > <https://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers>), > or if this is just for development, then Chrome at least has a checkbox in > the developer tools for disabling caching. > > Cache-control is evil. Users concerned with seeing the most up-to-date > information know to hit reload (and probably do anyway, just to be sure), and > there's also the option of AJAX polling for that (or whatever precisely sites > like Facebook do). > > Meanwhile, cache-control has all of the following very annoying consequences > for users (at lease one of which hits the web site too): > > * Every page load and navigation step is painfully slow because of all of the > various reloading assets and such, if the user is on any typical consumer > "broadband" connection rather than real broadband. > * In particular, normally instant back-arrow and forward-arrow navigation are > annoyingly slow. > * If the user's connection is noticeably flaky, then the page is likely to > only partly load, and using back-arrow forward-arrow to try to force the > missing elements to load also loses the elements that were already loaded, > instead of incrementally loading more and more of the page until eventually > it's all there. > * It costs both the user and the web site bandwidth. Important to you, and > important to at least your mobile users, who probably have metered *and* > tightly capped data plans. > * In Firefox, at least, cache-control breaks image right-click save-as, > because right-click save-as just copies the cached image normally, but if > it's not cached instead tries to download it again. If that's combined with > typical hotlinking blocking, the result tends to be errors or corrupt jpegs. > To see this effect go to a Photobucket album, which serves either the image > itself or a webpage with the image in it depending on referer and which also > uses cache-control. If you right-click save-as the image you'll get a corrupt > jpeg file that, when opened in Notepad, is actually full of HTML. Of course, > blocking hotlinking and playing "clever" redirection tricks with referer is > evil too, but cache-control compounds that evil a thousandfold. (The only > correct use of referer is for log analysis to discover how your users > navigate around your site. Using it to discriminate against users based on > where they were linked in from is evil and wrong.) > > Upshot: Use Ajax push/pull if you really want users to always see up-to-date > information, and otherwise let them use "refresh" as appropriate. And don't > get cute serving different content for the same URI depending on referer; > that's just wrong. :) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > <http://groups.google.com/group/clojure?hl=en> > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
