From: shelby at coolpage dot com Operating system: Irrelevant PHP version: 4.4.2 PHP Bug Type: Output Control Bug description: JSON needs set_error_handler to capture all error types
Description: ------------ A new issue that should re-open bug #12136: http://bugs.php.net/bug.php?id=12136 When server-side output is header( "Content-type: application/json" ), when the client is receiving input via XHttpRequest::responseText, then server-side all error types need to be captured and converted to JSON output, else client needs to do special detection to handle other inpyt Content-types. By default, PHP server-side outputs errors in "Content-type: text/html". Thus the client will need to detect these using XHttpRequest::getResponseHeader() and assume they are always errors. This client assumption that all "text/html" input are errors is logically inconsistent (not OO). Rather the correct programming construct is that errors should be encoded server-side as JSON output, so that client can logically detect errors not by Content-type, but by an encoding which specifically identifies them as errors. Also this would enable presentation of errors in alert(), not forcing them to be presented in HTML. The justification "by design" in Bug #12136, makes the point that the engine may be unstable after the occurrence of certain errors and thus implying that allowing user callback handling could be unreliable. Hmmm. Lesser of evils? Seems to me that if the engine is stable enough to write out the error in HTML, then should a simplistic user function to write out the error in JSON (or whatever) be less stable? Instead of allowing all error types in set_error_handler(), should error_reporting() have an optional input argument for "Content-type" and support minimally XML and JSON? This bug report is very important for the Web2.0/AJAX revolution. -- Edit bug report at http://bugs.php.net/?id=38184&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38184&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38184&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38184&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38184&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38184&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=38184&r=needscript Try newer version: http://bugs.php.net/fix.php?id=38184&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38184&r=support Expected behavior: http://bugs.php.net/fix.php?id=38184&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38184&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38184&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38184&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=38184&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38184&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38184&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=38184&r=mysqlcfg
