Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 21472 invoked by uid 500); 6 Feb 2003 01:38:22 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 21461 invoked from network); 6 Feb 2003 01:38:22 -0000 Message-ID: <3E41BCC0.8020901@pcextremist.com> Date: Wed, 05 Feb 2003 17:39:12 -0800 From: Miles Elam User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: [OT] Re: [TIPS] Basic configurations of Apache 2.0 for Cocoon 2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org