Re: HTTP_ACCEPT_LANGUAGE

--===============73550842069277111==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-11--1404237"
Content-Transfer-Encoding: 7bit


--Apple-Mail-11--1404237
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Feb 14, 2004, at 04:38, Moritz Bunkus wrote:

>> 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
>
> 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.

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).

> 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}

--Apple-Mail-11--1404237
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAMxb7IEPQ5f5vKv0RAk+3AJ9NZ5QoLapsvQMu0N8w+TOM+x0pDQCeKtUy
ACsqBsLqYVrqvRLVkWulIdU=
=nKzu
-----END PGP SIGNATURE-----

--Apple-Mail-11--1404237--



--===============73550842069277111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Anthill-workers mailing list
Anthill-workers-+mQDA36h6dWw5LPnMra/[email protected]
http://vmlinuz.ca/mailman/listinfo/anthill-workers

--===============73550842069277111==--