If this was implemented, it should be a unique id once per CSS change, not once per application start.
E.g. we deploy to production every few weeks, and client browsers should be able to cache files that entire time until change them, regardless of reboots. But obviously a value once per application start is much easier. I think what this points out is that its the file's datetime that is the state that needs to be used here, and the existing mechanism of HTTP looks like the way to go. Perhaps I'll dig into it and try to understand why this is not working as one would expect. On Feb 12, 1:28 pm, Marius <[email protected]> wrote: > Oh yes I did and I hate it. Ironically I was about to propose a > solution for this. > > instead of > > <link rel="stylesheet" type="text/css" href="mycss.css"/> > > do something like: > > <lift:css name="mycss.css" /> > > this would render: > > <link rel="stylesheet" type="text/css" href="mycss.css? > i784yrfiuhferfhweir57=_"/> > > the query string parameter would be generated at application start-up. > If you update you css/js and restart the application the browser will > refresh it. Potentially generating the random query string param could > be a LiftRules function that by default generates a sequence once per > application time. Thus you could potentially set your own function > that reads this for a config file? > > Similarly <lift:js name="myjs.js"/> would do the same. > > Br's, > Marius > > On 12 feb., 19:25, Alex Black <[email protected]> wrote: > > > I'm wondering if other people have encountered this issue, or if we're > > doing something wrong, or if there is a nice solution to this. > > > Whenever we update our site, with new code and CSS and JS, any user > > who visits it gets OLD css and js files (from their browser cache) > > unless they force a refresh. > > > This is a jarring experience, users's see the site with old CSS and > > old JS which is effectively broken. > > > Any thoughts? If it helps, our site is athttp://snapsort.com. We're > > using Jetty, behind nginx. > > > I notice that when the browser requests the CSS files, the server > > responds 304 not modified, so I figured if the CSS was modified (when > > we update) then the server would not respond 304 not modified :) > > > - Alex -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
