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:
Even applying full JSON parsing (or any "Content-Type" parsing) will
not workaround the problem, because if the error occurs in the middle
of the content, the client will be unable to extract the error message
and present it. Thus error reporting is effectively off.
That is why I say the only generalized workaround is to turn off error
reporting. Thus it is a bug that turns off error reporting in
generalized case. How is turning off error reporting less reliable
than allowing set_error_handler to attempt process all error type (even
if engine has become unstable)?
The generalized fix would be to fix the engine so that it is not
rendered unstable by errors. One would think you already have achieved
such, given the existence of try-catch error trapping.
Seems the limitation placed on set_error_handler is now unnecessary?
Previous Comments:
------------------------------------------------------------------------
[2006-07-23 06:37:12] shelby at coolpage dot com
Someone changed this bug to to Feature Change Request. I have changed
it back to Output Control bug, because currently there is no way to
prevent error_reporting from outputting content which violates (a BUG)
the header( "Content-Type..." ) of the script (when it is not
"text/html"), except to turn error_reporting off.
Sorry to say, this is a bug, as it can cause the client web app to
function incorrectly, or it can cause the reporting error to be not
reported. There is no generalized workaround possible (if the error is
generated in middle of non-"text/html" content), other than to turn off
error reporting. How could you not define this as a bug?
------------------------------------------------------------------------
[2006-07-22 12:04:03] shelby at coolpage dot com
Obviously the workaround does nothing for the case where the "{" has
already been output (or if PHP decides to output "{" as first char of
it's errors), and then PHP generates an HTML error into the middle of
the JSON output.
I guess the more reliable client side workaround should use a full JSON
parser.
------------------------------------------------------------------------
[2006-07-22 12:00:25] shelby at coolpage dot com
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.
------------------------------------------------------------------------
[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
