Cookie control variables makes it possible to control the debugging environment from a program in another browser window. This would be prefereble with complex web pages (framesets, etc). The page is viewd as normal in one window. All debugging data is shown i another window, that also provides controls to alter the debugging environment. (But this external debugging program is not yet implemented.)

Environment control variables makes it more easy to globaly set the debugging environment for a web site. It is also a way for the target program to control the CGI::Debug module actions.

The four methods can be mixed. (Cookies, enviroment, import parameters and defaults.) The module will try to make sense with whatever you give it. The possibilites of control are more limitied in the Cookie / ENV version.

Report data for the debugging of the module itself, including everything else. Data::Dumper will be used, if found.

If the module itself dies, you will probably not get any output at al. You can check for errors in the file /tmp/CGI-Debug-error-$$. In order to see what error CGI::Debug is generating, you could changing $DEBUG to 2 or more, in the module file itself. Please email the author about any problems.

The report will come after any program output. The module will assume the page is in text/html, unless "header control" is set, in case this will be checked. (In none HTML mode, the header and delimiter will be ASCII.)

There is many cases in which faulty or bad HTML will hide the report. This could be controled with "report html_compliance" (which is not yet implemented).

The default mailaddress is the owner of the cgi program. This function requires the Mail::Send module. If there is any problem with the default behaviour of Mail::Send, set the enviroment variables, as described in the POD for Mail::Mailer, either for the HTTP server, or before "use CGI::Debug" in a BEGIN block.

The idea is to specify an email address that will be used if anybody besides yourself is getting an error. You will not get your own errors as email if you overide that action with a control cookie.

This control will follow the HTTP RFC to the point. It reports if the header is ok, if the content-type is text/html, and the length of the HTTP-body. That information will be used by other parts of CGI::Debug. This is done by redirecting STDOUT to a temporary file. This is the only control that must be set in the beginning of the program. All other controls can be changed during before the end of the program.

This is the only action that CHANGES THE BEHAVIOUR of your program. You will have to insert your own header if you remove the CGI::Debug row. But this action will guarantee that you have a valid header, without the need to save STDOUT to a temporary file.

Set what page to redirect to if there was an error report, not sent to browser.

This will show up in the browser if the error is going somewhere else. If no page is specified, a short generic CGI error response will show up. But if the CGI program succeeded in printing a valid http header and something in the body, that will be showed instead, even if the program later crashed.

CGI::Debug will not function under mod_perl. The only solution to get similar functionality is to develop a replacement for Apache::Registry, with integrated debugging features. The configuration interface can not include the "use CGI::Debug ( report => ... )" style, in a mod_perl version.

If you run CGI::Debug under mod_perl, it will do nothing, except sending a warning to STDERR.