httpd-dev mailing list archives

On Tue, Sep 05, 2000 at 11:21:23AM -0700, rbb@covalent.net wrote:
> On Tue, 5 Sep 2000 TOKILEY@aol.com wrote:
>
> > In a message dated 00-09-05 12:52:14 EDT, Ryan writes...
> >
> > > If we have a filter that converts from HTML to WML, then
> > > we want the error page to go through that filter.
> >
> > Exactly.
> >
> > The ONLY issue with this current message thread
> > ( using the HTML to WML example ) is what if the
> > HTML to WML filter itself has generated the ERROR and
> > that error page is the one that needs to be 'sent back'?
>
> Quick question. Is this an issue? We are talking about the canned error
> messages. Those are the messages associated with 3xx, 4xx, and 5xx error
> codes. Do we really think that required filters will be generating those
> error codes? I don't know, which is why I am asking. I am trying to
> envision a case where an HTML to WML filter will be generating those error
> codes, and I'm not seeing it.
500 (Internal Server Error) is quite possible. I could also see a WML filter
issuing a 301/302 to a different server (e.g. a specialized WML server).
> Also, if we look at ap_die, there is already logic to ensure that we don't
> recurse infinitely. Can we use the same general logic for filters?
Sure, I'd think so.
I think that I'm in the camp of restarting a request for errors (rather than
using filters as content generators).
Hmm... Actually, it would be quite easy to use the subrequest system to set
up an (error) content generator and its filter stack (if any). Spin up the
subreq, run it, and then exit the request (since this is usually being run
from ap_die()). Note that ap_die() can also call ap_internal_redirect() to
generate error message... I think we do the same kind of process, but it
sets up an error content generator rather than redirecting to a URL.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/