Re: ring - setting no-cache for everything?
On Friday, June 19, 2015 at 12:14:10 PM UTC-4, Thomas Heller wrote: 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). I don't even a wrong Cache-Control will cause problems but Cache-Control is probably one of the most important headers to set for your webapp. It is also one of the harder ones to get right but the benefits are significant. As for preventing users from seeing stale CSS/Javascript I'd recommend serving files with a unique name which changes with each new release. Doing that will break bookmarks and deep links! Unless you keep all the old versions around, with ways to get to the newest for users who want to. It's almost always better to rely on the user knowing when to reload (to be sure they have the latest) and when to use the Wayback Machine (for when they specifically want to look at an old version). The latter also works much better if the URL for your page stays stable, so all of its versions are presented with a single timeline on that site. Do what you suggested with *just* the CSS/JS files, maybe, but do not do it with the page itself, or images or other stuff meant for the end user to see! Though then the user will still have stale scripts until they reload and get a new version of the page pointing to the new scripts. Which then means you need to update every HTML file on the site every time you change to a new version of some script, so that it now points to the new scripts ... which is another giant mess that suggests it's better to just keep all of them at stable URLs too and rely on the browser reload button DTRT by checking all assets for 304 Not Modified vs. shiny and new. -- 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.
Re: ring - setting no-cache for everything?
Sounds like your URLs could use some cache busting. :) Then you can add far future Expires headers, with no worries that users are seeing stale files. Optimus is one way to inject some front-end performance in your Ring-app. https://github.com/magnars/optimus On Friday, June 19, 2015 at 11:00:57 AM UTC+2, Colin Yates wrote: Hi all, is there a quick way to disable caching for everything or alternatively hash based on the contents of the resource. I am talking specifically about CSS and javascript issues served from the JAR's class path? -- 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.
Re: ring - setting no-cache for everything?
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
Re: ring - setting no-cache for everything?
It is worth mentioning for others that if you are using ring.middleware.defaults/wrap-defaults then this middleware is already in play. On 19 Jun 2015, at 10:53, James Reeves ja...@booleanknot.com 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. - James On 19 June 2015 at 10:00, Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com wrote: Hi all, is there a quick way to disable caching for everything or alternatively hash based on the contents of the resource. I am talking specifically about CSS and javascript issues served from the JAR's class path? -- 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 mailto: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 mailto:clojure%2bunsubscr...@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 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.
Re: ring - setting no-cache for everything?
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.
Re: ring - setting no-cache for everything?
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. - James On 19 June 2015 at 10:00, Colin Yates colin.ya...@gmail.com wrote: Hi all, is there a quick way to disable caching for everything or alternatively hash based on the contents of the resource. I am talking specifically about CSS and javascript issues served from the JAR's class path? -- 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. -- 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.
Re: ring - setting no-cache for everything?
Thanks James. On 19 Jun 2015, at 10:53, James Reeves ja...@booleanknot.com 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. - James On 19 June 2015 at 10:00, Colin Yates colin.ya...@gmail.com mailto:colin.ya...@gmail.com wrote: Hi all, is there a quick way to disable caching for everything or alternatively hash based on the contents of the resource. I am talking specifically about CSS and javascript issues served from the JAR's class path? -- 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 mailto: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 mailto:clojure%2bunsubscr...@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 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.
Re: ring - setting no-cache for everything?
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). I don't even a wrong Cache-Control will cause problems but Cache-Control is probably one of the most important headers to set for your webapp. It is also one of the harder ones to get right but the benefits are significant. As for preventing users from seeing stale CSS/Javascript I'd recommend serving files with a unique name which changes with each new release. This way old HTML refers to old CSS and new HTML to new CSS, plus you can add Cache-Control: public, max-age=31536000 to the static files which allows the browser to actually SKIP checking if a resource was modified (ie. huge speed gains, no if-modified-since-not modified round trip). Disabling cache is usually the least desirable option and if you care about performance at all you should think twice before doing so (yes, even for intranet sites). /thomas -- 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.
