I found these The error handling output was found to not properly escape HTML output in > certain cases. An attacker could use this flaw to perform cross-site > scripting attacks against sites where both display_errors and html_errors > are enabled. >
http://www.nessus.org/plugins/index.php?view=single&id=21594 https://bugs.gentoo.org/show_bug.cgi?id=125878 I like PHP being configured for production, the safer approach. Does xdebug strictly depend on this setting? On 24 June 2011 09:55, Pierre Joye <pierre....@gmail.com> wrote: > hi, > > On Thu, Jun 23, 2011 at 11:40 PM, Derick Rethans <der...@php.net> wrote: > > > They are not useful in production, but as distributions use the > > "php.ini-production", even PHP developer that uses a distribution > > package now doesn't use the "php.ini-development" settings. Hence, no > > more HTML errors and people bitch. > > It looks to me like a distro bug or feature request, not a php issue. > They should (and I remember having asked ubuntu to provide such > option) ask the users which kind of environment they wish. > > > They "depend" by choice. Xdebug simply enhances how things show up, and > > does not want to mess with the settings that people have already made, > > as that's even a larger WTF point. > > > > The main points are that: > > > > 1. the default changed between 5.2 and 5.3, and I'd like to restore it > > 2. html_errors shouldn't mean that the docref stuff is turned on > > automatically. The docref stuff is the annoying part, not the HTML > > formatting. HTML formatting in production is *not* a problem (you > > should have display_errors=0 anyway). > > Main goal: make it easier for developers. > > That brings one question, what were the reasons to change that back > then? And why is it a good thing to restore them now, besides xdebug? > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
