ID: 38184
User updated by: shelby at coolpage dot com
Reported By: shelby at coolpage dot com
Status: Open
Bug Type: Output Control
Operating System: Irrelevant
PHP Version: 4.4.2
New Comment:
Detecting the "Content-Type" with XMLHttpRequest::getResponseHeader()
is not a workaround, because PHP's built-in error output does not
override the header( "Content-type: application/json" ) set by the PHP
script.
So the workaround gets even more bizzare, with the client having to
parse the XMLHttpRequest::responseText for JSON syntax errors to
determine it isn't JSON. <sarcastic>What a wonderfully reliable form
of error reporting</sarcastic>!
For now my workaround is I make sure the 1st char of JSON server-side
output is "{", then client side I do
XMLHttpRequest::responseText.chatAt( 0 ) != "{" to detect that a PHP
error has been received instead of JSON.
Correct typo: I meant XMLHttpRequest, not XHttpRequest.
Previous Comments:
------------------------------------------------------------------------
[2006-07-22 10:23:43] shelby at coolpage dot com
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 this bug report at http://bugs.php.net/?id=38184&edit=1
