New INIs, Round Two.

16 years ago by Eric Stewart — view source — reply

unread

I've gone through and made changes based on pretty much all the comments
I've received. Here is a summary of most of the changes I made.

Change the About this file section to be useable (unmodified) in both
production and development files.
Revised the quick reference section to include default, development and
production values in both files. This was done to make it more useful and
reduce the differences between the two INIs. It was suggested that this new
section be removed completely and was suggested that diffing the production
and development files would produce essentially the same thing. This is
incorrect as the main reason for this section is to point the differences
between these files and PHP's default behavior. Diffs aren't going to help
with that. It was also suggested that we move all the directives with
setting differences to the top of the file for ease of use. I like the way
the directives are currently grouped by association. Re-ordering the
directives which have different values than the default breaks that
grouping. I think this quick reference section achieves both goals somewhat
elegantly.
I've attempted to reduce the overall differences between the production
and development INIs to only setting changes. All commenting and white
spacing should now be the same between both documents.
I mistakenly had the development and production values of
allow_call_time_pass_reference reversed. This error has been corrected.
The development value of output_buffering has been changed to match the
production value for reasons of operational consistency.
The development value of register_argc_argv has been changed to match the
production value for reasons of operational consistency.
The development value of request_order has been changed to match the
production value for reasons of operational consistency.
The development value of session.gc_divisor has been changed to match the
production value for reasons of operational consistency.
The development value of variables_order has been changed to match the
production value for reasons of operational consistency.
The development value of error_reporting has been changed to E_ALL |
E_STRICT.
The production value of error_reporting has been changed to E_ALL |
~E_DEPRECATED.
The comments regarding section headers have been revised to include
information regarding [HOST= and [PATH=.
The oci8.events and oci8.old_oci_close_semantics example values now use
the boolean constants.
Many people have asked why the links to the online documentation for
each directive are specifically to the English version. The answer is that I
was a dope when I was copying and pasting them. My bad. Unfortunately,
subsequent research of using non-language specific links has revealed that
the directive specific anchors, which take you right to the directive and
not just the page, are removed upon the redirection that follows when PHP
determines your language and forwards you to the documentation specific to
lang of your browser. This certainly reduces the usefulness of those links.
I've made a few attempts to contact people regarding this. I have every
intention of removing the English biased to these links but I'm not quite
sure how the new links should be formatted yet. Stay tuned for details and
please contact me if you have a solution or can help the creation of one.
A few other directives have been question but I don't have enough
experience with these particular settings so please weight in on them.

extension_dir = "./"
enable_dl = On

Take a look when you get a chance and let me know how things look now.

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

Eric Stewart

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

The production value of error_reporting has been changed to
E_ALL |
~E_DEPRECATED.

I guess you mean E_ALL & ~E_DEPRECATED

16 years ago by sean finney — view source — reply

unread

hi,

A few other directives have been question but I don't have enough
experience with these particular settings so please weight in on them.

extension_dir = "./"
enable_dl = On

i'd be incredibly weary of this setting, even in a development environment.

if you have enable_dl on, a user can load an arbitrary .so into php's (and
thus most often apache's) memory space.
if you have extension_dir = "./", then even open_basedir and similar
built-in restrictions about the path of dl()'d .so extensions are no
longer in effect, and the floodgates are opened for various types of
external attacks.

the biggest reason that this is problematic is that in the case of
apache, you have raw access to all of apache's memory, including ssl keys,
stored passwords, etc, which typically a php script will not have.

sean

16 years ago by Hannes Magnusson — view source — reply

unread

hi,

A few other directives have been question but I don't have enough
experience with these particular settings so please weight in on them.

extension_dir = "./"
enable_dl = On

i'd be incredibly weary of this setting, even in a development environment.

if you have enable_dl on, a user can load an arbitrary .so into php's (and
thus most often apache's) memory space.

dl() should indeed be disabled by default (and the NEWS entry says it is).
dl() support has furthermore been removed from most SAPIs, and
according to the NEWS entry it is only available for cli, cgi and
embed.
Actually, the docs and NEWS are a bit inconsistent on that, the docs
say the function just raises E_DEPRECATED while the NEWS entry makes
it sound like dl() simply wont work as apache module..

-Hannes

16 years ago by johannes@php.net — view source — reply

unread

hi,

A few other directives have been question but I don't have enough
experience with these particular settings so please weight in on them.

extension_dir = "./"
[...]

if you have extension_dir = "./", then even open_basedir and similar
built-in restrictions about the path of dl()'d .so extensions are no
longer in effect, and the floodgates are opened for various types of
external attacks.

extension_dir should be the compiled-in by default, at least on *nix. On
windows maybe the installer can set it. So the value should be commented
out.

On *nix the reason is that the compiled in default (for example
$prefix/lib/php/extensions/no-debug-non-zts-20090115) is used when
compiling extensions using the phpize-way or pear installer so only with
that value it will work out of the box.

johannes

16 years ago by Ilia Alshanetsky — view source — reply

unread

A few other directives have been question but I don't have enough
experience with these particular settings so please weight in on them.

extension_dir = "./"
enable_dl = On

I think enable_dl should be off by default in both production and test
environments. Aside from being a somewhat a security risk, I think our
overall policy has been to discourage the use of dl() to dynamically
load extensions into PHP.

Ilia Alshanetsky

16 years ago by Christopher Jones — view source — reply

unread

Eric,

Should uncommented parameters that seem to have the default value be
commented out? For example "asp_tags" and "precision". If the
parameters don't always have the same default value everywhere, should
they be documented in Quick Reference section as having a different
value to the default?

Eric Stewart wrote:

I mistakenly had the development and production values of
allow_call_time_pass_reference reversed. This error has been
corrected.

I really think this should be Off in both cases to discourage use.
The doc http://www.php.net/ini.core says "This method is deprecated
and is likely to be unsupported in future versions of PHP/Zend."

The production value of error_reporting has been changed to E_ALL |
~E_DEPRECATED.

This should use '&', as Dave already pointed out on the list.

The oci8.events and oci8.old_oci_close_semantics example values now use
the boolean constants.

Thanks.

Many people have asked why the links to the online documentation for
each directive are specifically to the English version.

Regardless of the language issue, can the URLs consistently use "www"
instead of "us2"? At the moment both occur.

Can the generic case in this come first:?

; 6. Windows directory (C:\windows or C:\winnt), or --with-config-file-path
; compile time option.

i.e change it to

; 6. The directory from the --with-config-file-path compile time
; option, or the Windows directory (C:\windows or C:\winnt)

The general documentation could mention the use of variables as seen
in ext/standard/tests/general_functions/parse_ini_basic.{phpt,data}:

basicval = bar
var1 = ${basicval}

The general documentation could mention that absolute paths to
extensions are (now) supported:

extension=/path/to/extension.so

This should use "its" not "it's":

; PHP attempts to find and load this configuration from a number of locations.
; The following is a summary of it's search order:

The first "it's" below should be "its":

; php.ini-development is very similar to it's production variant, except it's
; much more verbose when it comes to errors.

This should be "its" in:

; php.ini-production contains settings which hold security, performance and
; best practices at it's core.

Ditto in:

; Turning on this setting and managing it's maximum buffer size can yield some

Ditto in:

; Integer = Enables the buffer and sets it's maximum size in bytes.

Ditto in:

; this to 1 will cause PHP CGI to fix it's paths to conform to the spec. A setting

There's an (existing) typo in this description, I guess "ignore
libjpeg warnings" was the intention:

; Tell the jpeg decode to libjpeg warnings and try to create
; a gd image.

Chris

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

16 years ago by Eric Stewart — view source — reply

unread

Christopher,
I looked into the addition of the use of variables in the INI files and I
wasn't able to find much documentation on it. Also, I haven't been able to
play with them and see exactly how they work. For now I don't feel confident
in adding my own comments about it. If you want to write up the comments
about it, I'll be happy to include those.

Eric

On Tue, Feb 17, 2009 at 1:53 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:

Eric,

Should uncommented parameters that seem to have the default value be
commented out? For example "asp_tags" and "precision". If the
parameters don't always have the same default value everywhere, should
they be documented in Quick Reference section as having a different
value to the default?

Eric Stewart wrote:

I mistakenly had the development and production values of
allow_call_time_pass_reference reversed. This error has been
corrected.

I really think this should be Off in both cases to discourage use.
The doc http://www.php.net/ini.core says "This method is deprecated
and is likely to be unsupported in future versions of PHP/Zend."

The production value of error_reporting has been changed to E_ALL |
~E_DEPRECATED.

This should use '&', as Dave already pointed out on the list.

The oci8.events and oci8.old_oci_close_semantics example values now
use
the boolean constants.

Thanks.

Many people have asked why the links to the online documentation for
each directive are specifically to the English version.

Regardless of the language issue, can the URLs consistently use "www"
instead of "us2"? At the moment both occur.

Can the generic case in this come first:?

; 6. Windows directory (C:\windows or C:\winnt), or
--with-config-file-path
; compile time option.

i.e change it to

; 6. The directory from the --with-config-file-path compile time
; option, or the Windows directory (C:\windows or C:\winnt)

The general documentation could mention the use of variables as seen
in ext/standard/tests/general_functions/parse_ini_basic.{phpt,data}:

basicval = bar
var1 = ${basicval}

The general documentation could mention that absolute paths to
extensions are (now) supported:

extension=/path/to/extension.so

This should use "its" not "it's":

; PHP attempts to find and load this configuration from a number of
locations.
; The following is a summary of it's search order:

The first "it's" below should be "its":

; php.ini-development is very similar to it's production variant, except
it's
; much more verbose when it comes to errors.

This should be "its" in:

; php.ini-production contains settings which hold security, performance
and
; best practices at it's core.

Ditto in:

; Turning on this setting and managing it's maximum buffer size can yield
some

Ditto in:

; Integer = Enables the buffer and sets it's maximum size in bytes.

Ditto in:

; this to 1 will cause PHP CGI to fix it's paths to conform to the spec.
A setting

There's an (existing) typo in this description, I guess "ignore
libjpeg warnings" was the intention:

; Tell the jpeg decode to libjpeg warnings and try to create
; a gd image.

Chris

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