Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12688
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20040909183405.63450.qmail@pb1.pair.com>
To: internals@lists.php.net
Date: Thu, 9 Sep 2004 11:34:03 -0700
Lines: 26
Subject: PHP's error handler: xmlrpc_errors, entity encoding, and handler chaining
From: pollita@php.net ("Sara Golemon")

Going through some error handling code, I noticed that while Plaintext and
HTML errors use the error_prepend_string and error_append_string php.ini
directives in the construction of their error messages, XML errors do not.
Any particular reason for that?

I also notice that there's no htmlspecialchars() type treatment for the
error strings when used in HTML or XML mode.  Not exactly the most common
route for an XSS attack, and probably not one worth worrying about, but it
seems lacking.

One last thing:  error handlers can be pushed/popped on and off of a stack
using set_error_handler() and restore_error_handler(), and that's fine, but
with the recent addition of the ability to fallback on the default error
handler by returning an explicit FALSE from a user error handler, it may
seem non-intuitive to the end user that this feature flows ALL the way back
to the internal handler (skipping any prior handlers sitting on the stack),
while restore_error_handler() operates by restoring merely the most recent
handler.  Personally I'd like to see this follow the stack rather than jump
all the way back.

-Sara