Michael Peters wrote: > > Mark Stosberg wrote: >> Evan A. Zacks wrote: >>> Attached is a patch to address this problem. I have only tested >>> it running as a CGI, however. Does anyone know if this is a >>> reasonable approach to allowing fatalsToBrowser (or another >>> custom die handler) to pass through? >>> >>> The idea is that if a custom handler is installed, the >>> http_error() method should not generate any output, but should >>> rethrow the exception. >> The patch looks OK to me. If someone really wants to install a global >> signal handler /AND/ have http_error() display HTML in this case, they >> can locally disable the signal handle. > > I wonder if this isn't just a symptom of a larger problem. Dispatch tries > force > any errors to Do The Right Thing, which for me is to return the proper Apache > code so that an ErrorDocument is triggered, without me having to do anything > in > my app to get an error page. This is probably the Right Thing to do under > mod_perl. > > Under mod_cgi it tries to print a simple HTML page with the error. Maybe this > isn't The Right thing and we should be doing something else? CGI::Carp does > it's > thing via signal handlers, but that's just CGI::Carp. I'd rather not have a > specific work-around for CGI::Carp, but a good solution that will also work > for > CGI::Carp. Thoughts?
I suppose people could override http_error(),and we could document that better as an alternative. That would get us out of dealing directly with signal handler workarounds at all. Mark --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
