Hello Miles. Thats exactly what we did for implementing a "transparent" file caching system with apache 2.0 and cocoon.
You can use something like this (with mod_rewrite enabled): Alias /rsvgn/ "C:/cache/rs/" <Directory "C:/cache/rs"> RewriteEngine On RewriteCond %{REQUEST_FILENAME} "!-f" RewriteRule (.*) http://localhost:8081/cache/engine/rs/$1 [proxy] AllowOverride None Options Indexes FollowSymLinks MultiViews IncludesNoExec Order allow,deny Allow from all </Directory> It checks if a given files exists on the local hard disk (or in one of the subdirectory, that doesnt matter) and if this fails it redirects (invisible for the client becaus of the [proxy] directive) the request to the servlet engine. In our case the servlet engine processes the request and - in addition to that - writes the generated file to the hard disc, so the next time it comes from there without even doing a single request to the servlet engine. If the file gets invalidated because of a content update another process deletes the file from the file system. This is a special caching system which replaces the cocoon cache in some way for our special purposes. But if the cocoon cache suites you needs, you can do the same with cocoon. But in our solution you can switch off the serlvet at all, once the cache is populated fully, and the cache is 100% transparent for the administrator. Stefan > -----Original Message----- > From: Miles Elam [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 06, 2003 2:39 AM > To: [EMAIL PROTECTED] > Subject: [OT] Re: [TIPS] Basic configurations of Apache 2.0 > for Cocoon 2 > > > Here's a question for all you HTTPd heads out there. ;-) > > Is it possible now or reasonably straightforward to have > HTTPd look for > a static file and, upon failure, look up a fallback resource? For > example, if a user requests "/images/foo.png", HTTPd would > look up the > file on the filesystem. If the file wasn't there, it would > pass it to > the servlet engine (or whatever dynamic process available). > Hell, even > better: "/images/foo" that invokes HTTPd's content > negotiation and then > checks the dynamic pool(s). > > It's got filters now to pass the output of one module to the input of > another, but what about a process similar to nested try/catch > blocks? > The first, most efficient method fails, fall back to the > next, and the > next... > > - Miles > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]