RFC for new INI's

2009/2/10 Karsten Dambekalns karsten@typo3.org:

Hi Eric.

A new RFC for PHP's proposed INI files have been added to the wiki. Below
is
a direct link to the page.
http://wiki.php.net/rfc/newinis

I love the settings for production, but I think you reversed the meaning of
allow_call_time_pass_reference - if it is allowed no warning will be issued.
So, to make your intention of

---

; Default Value: On (Issue warnings)
; Development Value: On (Issue warnings)
; Production Value: Off (Suppress warnings)

work, you need to write that the other way around - 'Off' means 'issue
warnings'... It is:
Development Value: Off (Issue warnings)
Production Value: On (Suppress warnings)

In production session.bug_compat_42 is off, but according to the "summary"
you want it to be on for development (so that warnings about it are shown, I
assume). In the development php.ini the actual values for both settings are
off, though.

And I am not sure about register_argc_argv having different values in both
files. I understand ot being off in production for speed reasons, but if it
"just works" in development and "suddenly stops working" in production...
But that's a minor issues.

All in all like the proposed settings!

Regards,
Karsten

--

Regarding ...
"; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future."

This is no longer true. See http://docs.php.net/manual/en/ini.sections.php

I would suggest changing this to ...

"; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future. The exception to this rule is
; section headers starting with [HOST= and [PATH=
; See : http://www.php.net/manual/en/ini.sections.php";

Regards,

Richard Quadling.

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

Sorry to hijack, but ...

Christopher Jones wrote:

oci8.events and oci8.old_oci_close_semantics are boolean, so we can
take this opportunity to change the 1 and 0 to On and Off.

... I've never understood why writing On/Off is a good idea, when it is
not intuitive that the value returned from ini_get() is of a different
content (not meaning, however).

Or has this changed in more recent versions?

markus@dev01:~$ php -dregister_globals=Off -r
'var_dump(ini_get("register_globals"));'
string(0) ""
markus@dev01:~$ php -dregister_globals=On -r
'var_dump(ini_get("register_globals"));'
string(1) "1"
markus@dev01:~$ php -dregister_globals=0 -r
'var_dump(ini_get("register_globals"));'
string(1) "0"
markus@dev01:~$ php -dregister_globals=1 -r
'var_dump(ini_get("register_globals"));'
string(1) "1"
markus@dev01:~$ php -v
PHP 5.2.5-3+lenny1 with Suhosin-Patch 0.9.6.2 (cli) (built: May 27 2008
21:47:08)

regards,

• Markus

Hi,

Some suggestions:

Links: Instead of forcing language to english, allow autodetection from
http headers.

Before:
http://www.php.net/manual/en/ini.core.php#ini.user-dir

After:
http://www.php.net/ini.core#ini.user-dir

Also some things I think are not appropriate:

extension_dir = "./"
enable_dl = On
Setting extension_dir to this value allows an attacker to execute code using dl(). I believe at least enable_dl should be disabled on production systems.

Regarding register_argc_argv, you write:

; Development Value: On
; Production Value: Off

However it's off in both case (which seems better to me anyway). Just a matter of fixing comments?

For now that's everything that I saw, I'll take another look later :)

Mark

Le mardi 10 février 2009 à 08:17 -0800, Christopher Jones a écrit :

Eric Stewart wrote:

A new RFC for PHP's proposed INI files have been added to the wiki. Below is
a direct link to the page.
http://wiki.php.net/rfc/newinis

Eric Lee Stewart
ericleestewart@gmail.com

Eric,

Thanks for the work put into this. My comments follow.

Chris

---

The section on devel & prod setting differences looks nice but it does
become a maintenance task. Since diffing files is easy (and
relatively obvious), I'd suggest removing this section from the files.
You may want to keep it in the RFC text so reviewers can get a quick
idea of the intent of the differences. It's also not immediately
obvious from this section whether the given values are the defaults,
or what is set in each file, or set in the other file.

In the section on extensions. IIRC, you can now use absolute paths.

Change all "http://us2.php.net/manual/en/"; to "http://www.php.net/manual/";
(Maybe the doc team can confirm whether to keep the "en")

oci8.events and oci8.old_oci_close_semantics are boolean, so we can
take this opportunity to change the 1 and 0 to On and Off.

--
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Twitter: http://twitter.com/ghrd Free PHP Book: http://tinyurl.com/UGPOM

Eric Stewart wrote:

A new RFC for PHP's proposed INI files have been added to the wiki.
Below is
a direct link to the page.
http://wiki.php.net/rfc/newinis

Good work IMHO.

Similar to what Karsten Dambekalns wrote I think we should only have a
difference between devel and production for display/logging options,
but
not for options changing the 'behaviour' of PHP.

So I'd propose
allow_call_time_pass_reference = Off (devel) / On (production)
display_errors = On (devel) / Off (production)
display_startup_errors = On (devel) / Off (production)
html_errors = On (devel) / Off (production)
session.bug_compat_warn = On (devel) / Off (production)
track_errors = On (devel) / Off (production)

but
output_buffering = 4096 ; Changes header()/compression filter
behaviour

I think it makes sense to have it on in both.

register_argc_argv = Off ; Why should devel have access if prod
doesn't?

off in both.

request_order = GPCS ; Why should devel/production differ?
session.bug_compat_42 = Off ; Why should devel/production differ?

Agreed.

Ilia Alshanetsky

Hi.

session.bug_compat_42 = Off ; Why should devel/production differ?

Because in dev a warning should be shown, but the warning setting only
has an effect if this setting is on (at least that way it is documented
in php.ini).

Regards,
Karsten

Hi Eric:

http://wiki.php.net/rfc/newinis

Thanks for the work.

I noticed the actual directives in the files are the same. I guess
you
just focused on the Quick Reference section and getting the comments
set
up the way you want.

Line 488 in prod and 483 in dev need to have the link commented out.

error_reporting: should be E_ALL in production. Well written code
should not be generating notices, so notices indicate a problem that
needs fixing.

I think in dev environment it makes sense to set error reporting level
to E_ALL | E_STRICT

Ilia Alshanetsky

Hi,

variables_order: They should be the same on dev and prod.

request_order: Seems like it should be the same.

Caution! I've read several times in this thread that request_order
should be set to something that also contains C. This is DANGEROUS.
request_order was specifically introduced to determine the order of
variable merging that leads to $_REQUEST, while variables_order defines
the variables that are assigned at all (and without register_globals
and with request_order, the _order is actually misleading).

So: request_order should ONLY be set to "GP" in order NOT to have
cookies popping up in $_REQUEST - else everybody who uses $_REQUEST is
vulnerable to CSRF.

Also, a recommendation for request_order only makes sense as "GP" (on
both production and developement machine) and setting variables order
to "GPCS".

Furthermore, the comment in the ini file that request_order is in there
for performance reasons is just PLAIN WRONG and gives the impression
that setting it to "GPCS" or empty will just cost a little performance -
where it clearly allows for CSRF if people use $_REQUEST.

Regards,
Christian