HTTP_ACCEPT_LANGUAGE

[Moritz Bunkus]

Heya,

just installed 0.3.0 ;) Works fine so far.

Anyway, a problem that occured last time as well resurfaced when I
copied over the new files. In site.inc.php you check for the language:

if ($_SERVER['HTTP_ACCEPT_LANGUAGE'])

etc. Unfortunately this will print a warning in my case in the browser:
Notice: Undefined index: HTTP_ACCEPT_LANGUAGE in
/home/www/bunkus.org/html/anthill/include/site.inc.php on line 76

Is there a way in PHP to test if a hash actually contains a specific
key? If yes this warning can be avoided easily by testing for its
existance and anding that with the test if it actually has a useful
value.

Note: I'm still using Apache 2 with PHP4 as a cgi-bin executable.

Mosu

[Moritz Bunkus]

Heya again,

Post by Moritz Bunkus
if ($_SERVER['HTTP_ACCEPT_LANGUAGE'])

/me should look through the code before writing such mails.

Changing it into

if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE']))

solves it.

Mosu

[Vincent Danen]

Post by Moritz Bunkus

Post by Moritz Bunkus
if ($_SERVER['HTTP_ACCEPT_LANGUAGE'])

/me should look through the code before writing such mails.
Changing it into
if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE']))
solves it.

Committed to CVS. Thanks.

---
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}

[Dave Hall]

Hi Moritz,

That is a notice not a warning. PHP has several error reporting levels,
E_NOTICE reporting should not be used in production environments.

From the php manual ( see

http://www.php.net/manual/en/ref.errorfunc.php#ini.error-reporting ):
" In PHP 4 and PHP 5 the default value is E_ALL & ~E_NOTICE. This
setting does not show E_NOTICE level errors. You may want to show them
during development."

A way of avoiding this is to change the offending line to:
if (@$_SERVER['HTTP_ACCEPT_LANGUAGE'])

The "@" supressed the "error", but placing @s everywhere can hinder the
finding of real bugs when hunting for them. This is part of the reason
why the default error reporting level in PHP is E_ALL & ~E_NOTICE

Cheers

Dave Hall (aka skwashd)

PS /me returns to lurking

Content-Disposition: inline
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="7cm2iqirTL37Ot+N"


--7cm2iqirTL37Ot+N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Heya,

just installed 0.3.0 ;) Works fine so far.

Anyway, a problem that occured last time as well resurfaced when I
copied over the new files. In site.inc.php you check for the language:

if ($_SERVER['HTTP_ACCEPT_LANGUAGE'])

etc. Unfortunately this will print a warning in my case in the browser:
Notice: Undefined index: HTTP_ACCEPT_LANGUAGE in
/home/www/bunkus.org/html/anthill/include/site.inc.php on line 76

Is there a way in PHP to test if a hash actually contains a specific
key? If yes this warning can be avoided easily by testing for its
existance and anding that with the test if it actually has a useful
value.

Note: I'm still using Apache 2 with PHP4 as a cgi-bin executable.

Mosu

--=20
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds

--7cm2iqirTL37Ot+N--

[Moritz Bunkus]

Heya,

Post by Dave Hall
That is a notice not a warning. PHP has several error reporting levels,
E_NOTICE reporting should not be used in production environments.

From the php manual ( see

" In PHP 4 and PHP 5 the default value is E_ALL & ~E_NOTICE. This
setting does not show E_NOTICE level errors. You may want to show them
during development."

I see. (No, I'm not a PHP developper, obviously ;))

Post by Dave Hall
finding of real bugs when hunting for them. This is part of the reason
why the default error reporting level in PHP is E_ALL & ~E_NOTICE

I'm not suggesting to put a @ everywhere, but I don't want to unset
E_NOTICE either because it has saved my butt during the upgrade to
0.3.0: I kept my old config.inc.php, but it didn't contain
$_conf['crlf'], so the mails sent didn't contain ANY new lines
in the headers whatsoever. Funny result :) PHP printed out a couple of
notices, though, and I fixed that easily.

The warning levels are from the standard Debian PHP installation, and I
don't quite agree that E_NOTICE shouldn't be set on production
systems. The PHP apps I use here (phpmyadmin, phppgadmin) don't emit a
single of those, probably because they're programmed sensibly. Anthill
is programmed sensibly as well - it's just this one case where it
assumes that a hash key exists that actually doesn't. Like I've written,
a simple isset() around it solves that very nicely. It's definitely OK
to just access $_conf['whatever'] because the program can assume that
(for a normal installation) this key really exists. But the environment
variables the server/PHP binary sets are subject to change/not under the
control of the Anthill installation and should be checked.

Mosu

[Vincent Danen]

Post by Moritz Bunkus

Post by Dave Hall
finding of real bugs when hunting for them. This is part of the reason
why the default error reporting level in PHP is E_ALL & ~E_NOTICE

E_NOTICE either because it has saved my butt during the upgrade to
0.3.0: I kept my old config.inc.php, but it didn't contain
$_conf['crlf'], so the mails sent didn't contain ANY new lines
in the headers whatsoever. Funny result :) PHP printed out a couple of
notices, though, and I fixed that easily.

One thing you can do is turn off debug reporting in config.inc.php.
Set $_CONF['debug'] to 0 and you should get none of these (and likely
you'll want this in production unless you're noticing errors).

Post by Moritz Bunkus
The warning levels are from the standard Debian PHP installation, and I
don't quite agree that E_NOTICE shouldn't be set on production
systems. The PHP apps I use here (phpmyadmin, phppgadmin) don't emit a
single of those, probably because they're programmed sensibly. Anthill
is programmed sensibly as well - it's just this one case where it
assumes that a hash key exists that actually doesn't. Like I've written,
a simple isset() around it solves that very nicely. It's definitely OK
to just access $_conf['whatever'] because the program can assume that
(for a normal installation) this key really exists. But the environment
variables the server/PHP binary sets are subject to change/not under the
control of the Anthill installation and should be checked.

Agreed, which is why I've commited your change. It really is cleaner,
and shouldn't adversely affect anything. Either way, we're testing for
it, but one way, Anthill with the high debug reporting will report that
stuff whereas phpMyAdmin and others may not (AFAIK, they don't monkey
around with the reporting settings in PHP where I do... look in
site.inc.php for this:)

if ($_CONF['debug'] == 1)
{
error_reporting(E_ALL);
} else {
error_reporting(0);
}

Likely the others are setting at a much lower level by default (maybe
not 0, but certainly not E_ALL). That's all configurable via
config.inc.php.

---
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}