Re: [PHP-DEV] RFC for new INI's
Am 10.02.2009 um 03:27 schrieb Eric Stewart: 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 For -development, display_errors should *definitely* be on, and error_reporting should be E_ALL | E_STRICT. auto_globals_jit shouldn't be on, IMO. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC for new INI's
Hi Eric: On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote: 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. output_buffering: I agree with having it off in dev, since it encourages cleaner programming practices. Relying on buffering can lead to getting bitten when deploying to a server that has it off. variables_order: They should be the same on dev and prod. request_order: Seems like it should be the same. track_errors: I like this on in all environments. Functions exist that you need to get detailed error information but don't provide a way to get at them in the code other than $php_errormsg. Your comment that it's helpful for debugging dev servers undersells the this feature. session.bug_compat_42 and session.bug_compat_warn: The grammar in your comments needs cleaning up. Hmm, perhaps all of the comments do :), I haven't looked. Anyway, the worst offense is the use of a double negative: It's not recommended that you do not use this feature on production servers. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote: Hi Eric: On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
Hey, IMHO dev environment should be E_ALL | E_STRICT | E_DEPRECATED Regards, On Wed, Feb 11, 2009 at 2:19 PM, Ilia Alshanetsky i...@prohost.org wrote: On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote: Hi Eric: On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
On 11.02.2009, at 17:19, Ilia Alshanetsky wrote: On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote: Hi Eric: On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote: 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 Right. Currently E_DEPRECATED is also part of E_ALL. Maybe it should not. In dev env it should of course be enabled. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
Hi 2009/2/11 Guilherme Blanco guilhermebla...@gmail.com: Hey, IMHO dev environment should be E_ALL | E_STRICT | E_DEPRECATED E_DEPRECATED is apart of E_ALL (like Lukas just said), so I'd say: ; Development error_reporting = E_ALL | E_STRICT (5.3) error_reporting = E_ALL (6.0+) ; Production error_reporting = E_ALL | ~E_DEPRECATED Regards, On Wed, Feb 11, 2009 at 2:19 PM, Ilia Alshanetsky i...@prohost.org wrote: On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote: Hi Eric: On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
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 ericleestew...@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.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ini value of On = 1 and Off = ? (Re: [PHP-DEV] RFC for new INI's)
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? mar...@dev01:~$ php -dregister_globals=Off -r 'var_dump(ini_get(register_globals));' string(0) mar...@dev01:~$ php -dregister_globals=On -r 'var_dump(ini_get(register_globals));' string(1) 1 mar...@dev01:~$ php -dregister_globals=0 -r 'var_dump(ini_get(register_globals));' string(1) 0 mar...@dev01:~$ php -dregister_globals=1 -r 'var_dump(ini_get(register_globals));' string(1) 1 mar...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ini value of On = 1 and Off = ? (Re: [PHP-DEV] RFC for new INI's)
Markus Fischer wrote: 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, It improves human readability of php.ini, making it clear that the parameter value range is not numeric. when it is not intuitive that the value returned from ini_get() is of a different content (not meaning, however). It could possibly be argued there is an inconsistency somewhere, but then PHP type juggling and comparison have their own charm. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
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 ericleestew...@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.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC for new INI's
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 ericleestew...@gmail.com
