RE: [PHP-DEV] [PATCH] Redirect on Error
| From: | John Coggeshall | Date: | Tue, 26 Nov 2002 16:01:26 +0000 |
| Subject: | RE: [PHP-DEV] [PATCH] Redirect on Error | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-91749@lists.php.net to get a copy of this message | ||
Alrighty :)
I'm not going to force-feed localization down anyone's throat myself,
and since there are some who seem almost pissed at the idea... Well :)
Looks like there's just not a need for it.
Anyway... So what of my actual patch we were discussing at some point? I
never got a real answer as to if it would be suitable to commit.
John
>-----Original Message-----
>From: James Aylett [mailto:james.aylett@tangozebra.com]
>Sent: Friday, November 22, 2002 6:36 AM
>To: 'PHP Developers Mailing List'
>Subject: RE: [PHP-DEV] [PATCH] Redirect on Error
>
>
>> From: jani@localhost.localdomain
>[mailto:jani@localhost.localdomain]On
>>
>> What is so hard to understand in word 'FATAL'?
>> If your script doesn't work, what use is it to make it
>> show the cryptic 500 error??
>>
>> I'm -100000 for adding anything like this, even if and
>> even more then if it's optional.
>
>Returning a 500 is one of the easiest ways to automatically
>audit of fatal problems in your script, because it is
>(usually) pretty trivial to grab such status codes out of the
>access log. This is incredibly useful in build and test
>environments (we have automated processes trawling the logs on
>our dev, stage and production servers looking for problems).
>Indeed, you could go a step further with an ISAPI or Apache
>custom error handler (and presumably NSAPI, which I don't have
>experience of) to have immediate notification (useful if
>you've got a bunch of non-technical people testing out an interface).
>
>>From a user point of view, you can return an entity (say, an
>HTML page)
>>with
>a 500 error. Yes, this requires output buffering, but since
>this is all being mooted as an optional variant on error
>handling, that really shouldn't be counted against it. From
>the point of view of a non-human agent accessing such a page,
>you really /should/ return 500 so it's obvious that the
>request wasn't serviced properly. Returning an unparseable
>mess of pseudo-HTML really isn't useful in that many circumstances.
>
>I'm not qualified to comment on how feasible this sort of
>thing is for PHP, especially on all the SAPIs it supports, but
>as a user of PHP it is an option I'd be interested in.
>
>Cheers,
>James
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.370 / Virus Database: 205 - Release Date: 05/06/2002
>
>
>_______________________________________________________________
>_________
>This e-mail has been scanned for all viruses by Star Internet.
>The service is powered by MessageLabs. For more information on
>a proactive anti-virus service working around the clock,
>around the globe, visit: http://www.star.net.uk
>_______________________________________________________________
>_________
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>