[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cgiapp
Subject:    [cgiapp]  Re: Re: CGI::Application::Dispatch and fatalsToBrowser
From:       "Viacheslav Sheveliov" <vsheveliov () mail ! ru>
Date:       2006-10-22 21:26:29
Message-ID: ehgnmc$ubu$1 () sea ! gmane ! org
[Download RAW message or body]


"Michael Peters" <mpeters@plusthree.com> ???????/???????? ? ????????
?????????: news:45393B8A.8080305@plusthree.com...
>
>
> 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?



IMHO, fatalsToBrowser is useful in debug environment only. For website
visitors it gives no useful information, but hints for website hacking only.
So, may be it's reasonable to throw/don't throw errors depending on
$CGI::Applicaton::Dispatch::DEBUG.

For error printing under mod_cgi (and may be mod_perl?) may be used
ErrorDocument (error_document for good style :-)) C:A:D parameter instead of
not_found parameter.

Example

    CGI::Application::Dispatch->dispatch(
        ErrorDocument  => '/errors/error%s.html',
    );

    CGI::Application::Dispatch->dispatch(
        ErrorDocument  => '/cgi-bin/errors.cgi?error=%s',
    );


And sprintf in CGI::Application::Dispatch.
Howewer using redirect isn't very good idea, but simplicity...


-- 
Best regards,
 Viacheslav                          mailto:slavash@aha.ru








---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@lists.erlbaum.net
For additional commands, e-mail: cgiapp-help@lists.erlbaum.net

[prev in list] [next in list] [prev in thread] [next in thread]