Ivelin Ivanov wrote:
>>1. Would you like this addition to be committed to HEAD? If so I promise >>to come up with documentations and a short HOWTO on how to connect a >>reverse proxy with Cocoon. > +1 > > Is it possible that this is used in some fashion for dynamic pages as well? > In some cases the Action or Generator would have information as to whether > the underlying data model has changed and so they can in turn decide to > invalidate the cache. Hmmm... I'm not really getting it. By setting an Expires header you actually give up caching control to the client or to the reverse proxy, so once it's set it's not going to be invalidated anyhow. This might not be desirable. The point is what you think "dynamic pages" are. I see two scenarios: 1. real dynamic pages, e.g. built with request parameters, and changing everytime. In this case the Expires should never be set; 2. pages built dinamically, e.g. from an external news feed, that might change everytime but where it's acceptable to assume that it's not important to propagate the change to the final user before a given timeout. This is IMHO the majority of dynamic pages today. In this case having an Expires set might help a lot: consider a site which gets 100 hits per second, setting an Expires of 5 seconds might alleviate the burden on Cocoon by a factor of 500, with two Cocoon served requests serving up to 1.000 client requests. In 1. I don't really see how setting an Expires might help. Or am I missing something? Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
