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]

Reply via email to