> Yes, that's how it should work if everything was configured correctly > (which I think it wasn't for the OP)
Heh, I'm the OP. I'll have to dig into why its not working as expected I guess. > But what we were discussing (at least I was :-) was more that Lift > should serve resources with an "Expires" date in the far future. That > way the browser will only make a single request for a resource (as > long as the file is cached). This works well for returning visitors. > But of course an updated resource should be fetched, hence the unique > filenames. There are some things I like about that solution, but the unique filenames just seems wrong. So I see that a far in the future expires works, but the reason you need the unique filenames is because it doesn't really work. The far in the future expires says "you can cache this for a long time cause it won't change". The other option is say "you can cache this for like the next hour" but every time you fetch it, you can tell me when you last got it (conditional GET), and I won't send it to you if it hasn't changed (304 not modified). This results in more requests, but no need for unique filenames or anything, instead if the file changes then the server will serve it up to whoever needs it. > Combining individual files will improve load times for first time > visitors by reducing the number of requests. That sounds like a great idea.. would like the same thing for JS. Does the YUI compressor tool that lift uses with maven have this type of feature? I Thought I read that it did. > > /Jeppe -- 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.
