On 2012-04-08 16:37, Thijs Kinkhorst wrote:
On Sun, April 8, 2012 22:18, Filipus Klutiero wrote:
On 2012-04-08 13:07, Thijs Kinkhorst wrote:
On Sun, April 8, 2012 18:36, Filipus Klutiero wrote:
That's not an opinion, that's a bug. Compare
; Production Value: Off
with
short_open_tag = On
Off != On
I think what confuses you is that the comments in the php.ini indicate
what upstream considers production values, while what we ship is
different
from that because we do not think that short_open_tag necessarily needs
to
be off for environments considered 'production'.
That looks like it. debian/rules "sanitizes" php.ini files:
# sanitize php.ini file
cat php.ini-production | tr "\t" " " | sed -e'/short_open_tag =/
s/Off/On/g;/session.gc_probability =/ s/1/0/g;/disable_functions =/
s/$$/ $(PCNTL_FUNCTIONS)/g;'>
debian/php5-common/usr/share/php5/php.ini-production
cat php.ini-production | tr "\t" " " | sed -e'/memory_limit =/
s/128M/-1/g;/short_open_tag =/ s/Off/On/g;/session.gc_probability =/
s/1/0/g'> debian/php5-common/usr/share/php5/php.ini-production.cli
cat php.ini-development | tr "\t" " " | sed -e'/short_open_tag =/
s/Off/On/g;/session.gc_probability =/ s/1/0/g;/disable_functions =/
s/$$/ $(PCNTL_FUNCTIONS)/g;'>
debian/php5-common/usr/share/php5/php.ini-development
So it looks like we're changing the value of 3-4 default settings from
the upstream value, but we're not updating the corresponding
documentation.
I disagree. The comments contain advice by PHP upstream on what to do. We
supply this advice to the user, but at some points set other defaults.
That does not mean that the advice is necessarily wrong.
Right, I'm not saying any default value/advice is wrong. I'm just saying
the values disagree. For example, php.ini-production says in its
comments that the recommended production value of short_open_tag is Off.
But it actually recommends On.
By the way, regarding short_open_tag, according to php.ini
"php.ini-production contains settings which hold security, performance
and best practices at its core."
I don't think anyone disagrees with those goals.
and:
This directive determines whether or not PHP will recognize code between
;<? and ?> tags as PHP source which should be processed as such. It's
been
; recommended for several years that you not use the short tag "short
cut" and
; instead to use the full<?php and ?> tag combination. With the wide
spread use
; of XML and use of these tags by other languages, the server can
become easily
; confused and end up parsing the wrong code in the wrong context. But
because
; this short cut has been a feature for such a long time, it's
currently still
; supported for backwards compatibility, but we recommend you don't
use them.
So I don't think short_open_tag should be enabled in php.ini-production.
We're obviously well aware of these considerations by upstream. While the
principle is true that having short_open_tag Off is better, as with
everything there's a tradeoff involved. If you're starting an entirely
blank project from scratch, you really shoudl work only with the setting
off. However, the world is not perfect and there are uncountable amounts
of scripts out there that rely on this feature. We have to balance
breaking all this software against the benefits. Although the benefits as
they are described are real, they're not of extremely high importance.
This makes this case different from e.g. register_globals, where there's
also a large installed base of software relying on it, but the drawbacks
of that function are much much larger than that of short_open_tag, which
are relatively minor.
So the choices are 'ideal production setup' v.s. 'generally workable
defaults without too many adverse effects'.
Yes. We're discussing php.ini-production here, not the default php.ini.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
