Why are there no real error reports from the CGI scripts???

[carl_mcdade]

Abyss is not really developer friendly if it can't return the real CGI execution error. The error 200 page is very annoying and does not help when building a 1500 line script and needing only a line number to find a syntax error.

Is there anyway to improve this?

[aprelium-beta]

[carl_mcdade]

There is no problem with the error page itself but it stands in the way of the parse error returned from the perl or php exe. A parse error is automatically returned from the core functions of the CGI and should be written to screen. Abyss does not pick up these and returns a redirect to the error 200 page instead.

Example:

print $variable


Should return a missing ; error to screen because the default for the CGI exe is report all and its intern function should print this to screen.

This is not just a failing in the Abyss Server but all of the smaller personal web servers. To stand out from that crowd Abyss should have this feature in future versions.

[aprelium-beta]

carl_mcdade,

If your script interpreter (Perl for example) detects an error, this error is logged in the cgi.log file and the browser gets an error 500 page. This is more secure than displaying the error message to the users.
_________________
Beta Testing Team
Aprelium - http://www.aprelium.com

[carl_mcdade]

Hmm, Perl was not a good example because you have to explicitly turn that feature off on the server inorder to get a non 500 page. But in cases of PHP, ASP and Python the script error should be there.

As for showing the error the the visitor or user. This just re-enforces my arguement. The fact that the error is never captured and displayed properly for the developer makes it hard for the developer to write error trapping code that does not stop an application with a single HTML page. The developer can create proper error trapping and give the user a useful reponse.

But that is not the real problem. The main point is that without those default errors reports and warning messages from the interpreter, one may sit for days trying to find

on what line there is an extra }
on what line there is a ; missing
on what line there is an undeclared variable
on what line there is a escape character missing

The error reporting and notices should be configurable via the php.ini file or code. Many webservers do this correctly including omniHTTPD which is very small and fast. The reports should be coming as:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; error_reporting is a bit-field. Or each number up to get desired error
; reporting level
; E_ALL - All errors and warnings
; E_ERROR - fatal run-time errors
; E_WARNING - run-time warnings (non-fatal errors)
; E_PARSE - compile-time parse errors
; E_NOTICE - run-time notices (these are warnings which often result
; from a bug in your code, but it's possible that it was
; intentional (e.g., using an uninitialized variable and
; relying on the fact it's automatically initialized to an
; empty string)
; E_CORE_ERROR - fatal errors that occur during PHP's initial startup
; E_CORE_WARNING - warnings (non-fatal errors) that occur during PHP's
; initial startup
; E_COMPILE_ERROR - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; E_USER_ERROR - user-generated error message
; E_USER_WARNING - user-generated warning message
; E_USER_NOTICE - user-generated notice message

[aprelium-beta]

carl_mcdade,

No web server will detect errors and debug your scripts by itself. It is up to the interpreter you use to do so. Abyss and Apache act as a gateway between your script interpreter and the browser. It has nothing to do with syntax checks and errors detection.
So it is up to you to configure your script interpreter to display those errors or to put them in the log file.
For example, in PHP you should open php.ini and play with the error reporting settings there.
For example, change the value of error_reporting to