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]