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