httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] filtering and canned error responses
Date Wed, 06 Sep 2000 22:45:31 GMT
On Wed, Sep 06, 2000 at 10:20:29PM +0000, Tony Finch wrote:
> Greg Ames <> wrote:
> >
> >But that doesn't really address what Jeff was trying to fix when he
> >started this thread - the canned error text case.  In this case the
> >response may have different characteristics (charset pairs, content
> >type) than what the hook phases prior to the handler/generator have
> >decided and might be remembering.  So any filters that must be invoked
> >may do the wrong thing if we're not careful.  
> What I'm suggesting is that Apache's canned error responses should be
> generated by a special handler that is mapped into the URI space. (A
> little bit like the way Squid does it, but using a filename prefix
> rather than a special scheme.) E.g. /__internal__/error_404.html or
> anything that's reasonably unlikely to clash with existing URIs. Then
> when an error happens an internal redirect to the special URI occurs,
> which implies reconstruction of the filter stack.

I agree in concept, but there shouldn't be a need to generate a URI. Skip
those phases of execution (URI translation, file/directory walks, etc). Prep
the internal redirect (or subrequest or whatever), set its handler (builtin;
say "error-handler"), call a few of the hooks (dunno here; haven't
investigated which specific ones would be called), and then invoke the

> There does need to be a further fallback in case of egregious 500
> errors, e.g. when setting up the filter stack for an error, in which
> case there will have to me a hard-coded oh-my-god-everything's-broken
> filter stack probably comprising nothing but the core filter and an
> implementation -> network charset filter if necessary.



Greg Stein,

View raw message