We don't seem to have this problem with images.. Could this have to do with the fact that the CSS files and javascript are served out of the WAR file, whereas our images are served by a separate Jetty context?
On Feb 13, 3:35 am, Marius <marius.dan...@gmail.com> wrote: > On 12 feb., 22:56, Alex Black <a...@alexblack.ca> wrote: > > > If this was implemented, it should be a unique id once perCSSchange, > > 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 <marius.dan...@gmail.com> 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:cssname="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 youcss/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 <a...@alexblack.ca> 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 andCSSand JS, any user > > > > who visits it gets OLDcssand js files (from their browser cache) > > > > unless they force a refresh. > > > > > This is a jarring experience, users's see the site with oldCSSand > > > > 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 theCSSfiles, the server > > > > responds 304 not modified, so I figured if theCSSwas 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
