On 12 feb., 22:56, Alex Black <[email protected]> wrote: > If this was implemented, it should be a unique id once per CSS change, > not once per application start.
There is no proper API to see when file names are changed unless we poll. I prefer to have LiftRules function that by default takes a value generated at startup. User's can override it to generate the token more frequently depending on their use-case. > > 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. If you can dig deeper that would be useful. > > 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.
