# html_errors default settings
- Thread: https://externals.io/message/53550
- Original archive: https://news-web.php.net/php.internals/53550
- Started by Derick Rethans on 2011-06-23T19:47:52+00:00
- Messages: 16
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #53550 — Derick Rethans — 2011-06-23T19:47:52+00:00
URL: https://externals.io/message/53550#53550
Hi!
In PHP 5.2 and earlier, the html_errors setting has always been on by
default (in the code, in php.ini-dist and in php.ini-recommended). Since
PHP 5.3, it's still on by default in the code and in
php.ini-development, but php.ini-production has it off with the
following comment:
; When PHP displays or logs an error, it has the capability of inserting html
; links to documentation related to that error. This directive controls whether
; those HTML links appear in error messages or not. For performance and security
; reasons, it's recommended you disable this on production servers.
Right now, the docref is shown whenever html_errors=1, even if
docref_root is not set (empty string).
Sadly, this means that most distributions have it off in their php.ini.
Although the setting does influence the HTML links as well, it's by no
means a security (or performance) issue and it makes using PHP in
development a lot more annoying (because distributions have the
"production" version of php.ini, and not the "development" one.
It causes many many questions being asked why Xdebug doesn't show the
pretty errors and having it odd serves nothing. (In production, you
should set display_errors off).
A few examples:
http://cloudfysh.wordpress.com/2010/06/11/php-xdebug-not-formatting-var_dump/
http://stackoverflow.com/questions/4534312/xdebug-var-dump-function-colors
http://www.paoloiannelli.com/2011/04/15/solution-for-xdebug-not-overloading-var_dump/
http://stackoverflow.com/questions/2108576/unreadable-var-dump-output-on-snow-leopard
12:00 I just installed xdebug on my debian box
12:00 mostly for the nice output on error messages
12:01 but it doesn't work (i.e. I only get the default output)
12:01 any idea ?
12:01 http://xdebug.org/docs/faq#format
derick@xdebug:~/irclogs/OPN$ cat \#xdebug.log | grep 'faq#format' | wc -l
27
I'd like to revert this change *and* change when the docrefs are
shown, so that in 5.4 and trunk:
- html_errors is on by default again.
- the docref links are only shown when docref_root is not empty
A patch is attached. Comments?
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
---
## #53551 — Reindl Harald — 2011-06-23T21:02:38+00:00
URL: https://externals.io/message/53550#53551 · In reply to: #53550
Am 23.06.2011 21:47, schrieb Derick Rethans:
> Hi!
>
> In PHP 5.2 and earlier, the html_errors setting has always been on by
> default (in the code, in php.ini-dist and in php.ini-recommended). Since
> PHP 5.3, it's still on by default in the code and in
> php.ini-development, but php.ini-production has it off with the
> following comment:
>
> ; When PHP displays or logs an error, it has the capability of inserting html
> ; links to documentation related to that error. This directive controls whether
> ; those HTML links appear in error messages or not. For performance and security
> ; reasons, it's recommended you disable this on production servers.
>
> Right now, the docref is shown whenever html_errors=1, even if
> docref_root is not set (empty string).
>
> Sadly, this means that most distributions have it off in their php.ini.
>
> Although the setting does influence the HTML links as well, it's by no
> means a security (or performance) issue and it makes using PHP in
> development a lot more annoying (because distributions have the
> "production" version of php.ini, and not the "development" one.
> It causes many many questions being asked why Xdebug doesn't show the
> pretty errors and having it odd serves nothing. (In production, you
> should set display_errors off)
i would say it is the absolutely minmium requirement for anyone configuring
a server oder dvelop server-side scripts to know basic configurations
so if this is a problem for somebody he should consider not develop software
---
## #53552 — Derick Rethans — 2011-06-23T21:04:31+00:00
URL: https://externals.io/message/53550#53552 · In reply to: #53551
> so if this is a problem for somebody he should consider not develop software
Please drop this kind of unconstructive comments on this mailinglist.
Derick
---
## #53569 — Benno — 2011-06-23T21:18:36+00:00
URL: https://externals.io/message/53550#53569 · In reply to: #53550
Hi,
Op 23 jun. 2011 om 21:47 heeft Derick Rethans het volgende geschreven:
> Hi!
>
> In PHP 5.2 and earlier, the html_errors setting has always been on by
> default (in the code, in php.ini-dist and in php.ini-recommended). Since
> PHP 5.3, it's still on by default in the code and in
> php.ini-development, but php.ini-production has it off with the
> following comment:
>
> ; When PHP displays or logs an error, it has the capability of inserting html
> ; links to documentation related to that error. This directive controls whether
> ; those HTML links appear in error messages or not. For performance and security
> ; reasons, it's recommended you disable this on production servers.
>
> Right now, the docref is shown whenever html_errors=1, even if
> docref_root is not set (empty string).
>
> Sadly, this means that most distributions have it off in their php.ini.
>
> Although the setting does influence the HTML links as well, it's by no
> means a security (or performance) issue and it makes using PHP in
> development a lot more annoying (because distributions have the
> "production" version of php.ini, and not the "development" one.
> It causes many many questions being asked why Xdebug doesn't show the
> pretty errors and having it odd serves nothing. (In production, you
> should set display_errors off).
>
> A few examples:
>
> http://cloudfysh.wordpress.com/2010/06/11/php-xdebug-not-formatting-var_dump/
> http://stackoverflow.com/questions/4534312/xdebug-var-dump-function-colors
> http://www.paoloiannelli.com/2011/04/15/solution-for-xdebug-not-overloading-var_dump/
> http://stackoverflow.com/questions/2108576/unreadable-var-dump-output-on-snow-leopard
>
> 12:00 I just installed xdebug on my debian box
> 12:00 mostly for the nice output on error messages
> 12:01 but it doesn't work (i.e. I only get the default output)
> 12:01 any idea ?
> 12:01 http://xdebug.org/docs/faq#format
>
> derick@xdebug:~/irclogs/OPN$ cat \#xdebug.log | grep 'faq#format' | wc -l
> 27
>
> I'd like to revert this change *and* change when the docrefs are
> shown, so that in 5.4 and trunk:
> - html_errors is on by default again.
> - the docref links are only shown when docref_root is not empty
>
> A patch is attached. Comments?
>
> cheers,
> Derick
>
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
>
>
From the userland developer perspective this would certainly be nice.
Cheers,
Benno Crombeen
---
## #53553 — Stas Malyshev — 2011-06-23T21:22:49+00:00
URL: https://externals.io/message/53550#53553 · In reply to: #53550
Hi!
> I'd like to revert this change *and* change when the docrefs are
> shown, so that in 5.4 and trunk:
> - html_errors is on by default again.
> - the docref links are only shown when docref_root is not empty
What about CLI PHP?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
---
## #53554 — Ferenc Kovacs — 2011-06-23T21:26:27+00:00
URL: https://externals.io/message/53550#53554 · In reply to: #53553
On Thu, Jun 23, 2011 at 11:22 PM, Stas Malyshev wrote:
> Hi!
>
>
> I'd like to revert this change *and* change when the docrefs are
> > […]
>
> What about CLI PHP?
>
afaik that ignores the html_errors config already.
Tyrael
---
## #53555 — Ferenc Kovacs — 2011-06-23T21:27:15+00:00
URL: https://externals.io/message/53550#53555 · In reply to: #53554
>
>
> On Thu, Jun 23, 2011 at 11:22 PM, Stas Malyshev wrote:
>
> > […]
>
> afaik that ignores the html_errors config already.
>
> Tyrael
>
btw. I created an issue on this topic with #54537
ps: sorry for the double post.
Tyrael
---
## #53556 — Stas Malyshev — 2011-06-23T21:28:26+00:00
URL: https://externals.io/message/53550#53556 · In reply to: #53550
Hi!
> I'd like to revert this change *and* change when the docrefs are
> shown, so that in 5.4 and trunk:
> - html_errors is on by default again.
> - the docref links are only shown when docref_root is not empty
>
> A patch is attached. Comments?
Thinking more about this: if we're in production, that means
display_errors is off. So where exactly we expect to have these HTML
errors and how they are useful?
I have no idea why specific settings of xdebug depend on html_errors and
why xdebug can't have its own configuration setting to fix it if needed
- but this has nothing to do with PHP defaults IMO. I'd like to hear and
explanation how production setting of html_errors as 1 is useful.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
---
## #53557 — Derick Rethans — 2011-06-23T21:28:57+00:00
URL: https://externals.io/message/53550#53557 · In reply to: #53554
> On Thu, Jun 23, 2011 at 11:22 PM, Stas Malyshev wrote:
>
> > […]
>
> afaik that ignores the html_errors config already.
Yes, I am not changing that. html_errors is forcefully turned off in
CLI, just like the docs say:
; Note: This directive is hardcoded to Off for the CLI SAPI
cheers,
Derick
twitter: @derickr and @xdebug
---
## #53558 — Ferenc Kovacs — 2011-06-23T21:37:33+00:00
URL: https://externals.io/message/53550#53558 · In reply to: #53556
On Thu, Jun 23, 2011 at 11:28 PM, Stas Malyshev wrote:
> Hi!
>
>
>
>
> > […]
>
> Thinking more about this: if we're in production, that means display_errors
> is off. So where exactly we expect to have these HTML errors and how they
> are useful?
>
> I have no idea why specific settings of xdebug depend on html_errors and
> why xdebug can't have its own configuration setting to fix it if needed -
> but this has nothing to do with PHP defaults IMO. I'd like to hear and
> explanation how production setting of html_errors as 1 is useful.
>
>
xdebug does some fancy html around the output of the stack trace/var_dump
calls, and it only does that if html_errors is enabled.
usually you don't use xdebug in production, so it really doesn't matter
much.
but because we suggest in the production ini that it has a performance and
security impact, distros ships with html_errors turned off, which prevents
xdebug from enhancing the output.
I think that this could be changed back how it was before, but if many of
you think that this is a bad idea, then probably Derick should stop using
this config option for controlling this particular feature in xdebug, and he
could introduce a new option.
Tyrael
---
## #53562 — Derick Rethans — 2011-06-23T21:40:57+00:00
URL: https://externals.io/message/53550#53562 · In reply to: #53556
>
> > […]
>
> Thinking more about this: if we're in production, that means
> display_errors is off. So where exactly we expect to have these HTML
> errors and how they are useful?
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.
Not seeing errors because display_errors=0 is much more obvious.
> I have no idea why specific settings of xdebug depend on html_errors
> and why xdebug can't have its own configuration setting to fix it if
> needed - but this has nothing to do with PHP defaults IMO. I'd like to
> hear and explanation how production setting of html_errors as 1 is
> useful.
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.
cheers,
Derick
---
## #53565 — John Crenshaw — 2011-06-23T21:44:34+00:00
URL: https://externals.io/message/53550#53565 · In reply to: #53556
> I'd like to hear and explanation how production setting of html_errors as 1 is useful.
One that comes to mind is in conjunction with an error trap (output buffer hack to catch fatal errors and immediately notify an administrator). I could imagine using html_errors specifically because it would make it easier to parse the error from the output buffer.
Of course, in this case I see no reason why the error trap couldn't set html_errors at the same time as it sets display_errors and error_prepend_string.
John Crenshaw
Priacta, Inc.
---
## #53566 — Ferenc Kovacs — 2011-06-24T07:28:00+00:00
URL: https://externals.io/message/53550#53566 · In reply to: #53565
On Thu, Jun 23, 2011 at 11:44 PM, John Crenshaw wrote:
> > […]
> 1 is useful.
>
> One that comes to mind is in conjunction with an error trap (output buffer
> hack to catch fatal errors and immediately notify an administrator). I could
> imagine using html_errors specifically because it would make it easier to
> parse the error from the output buffer.
>
> Of course, in this case I see no reason why the error trap couldn't set
> html_errors at the same time as it sets display_errors and
> error_prepend_string.
>
>
for this, I prefer register_shutdown_function + error_get_last, it's way
more reliable than parsing the html errors.
Tyrael
---
## #53570 — Derick Rethans — 2011-06-24T08:48:42+00:00
URL: https://externals.io/message/53550#53570 · In reply to: #53550
[Ignore this thread, the ML was stupid last night]
---
## #53571 — Pierre Joye — 2011-06-24T08:55:32+00:00
URL: https://externals.io/message/53550#53571 · In reply to: #53562
hi,
> 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
---
## #53577 — devis@lucato.it — 2011-06-24T19:50:13+00:00
URL: https://externals.io/message/53550#53577 · In reply to: #53571
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?
> hi,
>
>
>
> > […]
>
> 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.
>
> > […]
>
> 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