Everything

php

FW: php fastcgi

php.internals

Dmitry Stogov

19 years ago

Hi,

Current time most PHP instalations use setting 'display_error=0'.
This setting hides errors from user but may send to him just a blank page.

The proposed patch sends HTTP 500 response on errors instead of blank pages.
The pages that already wrote something are not affectd.

Any objections or additions?

Thanks. Dmitry.

Richard Quadling

19 years ago

I think that's a good idea.

But wouldn't letting this be controlled in userland via
set_error_handler / set_exception_handler be just as good?

On 13/06/07, Dmitry Stogov <dmitry@zend.com> wrote:

> Hi,
>
> Current time most PHP instalations use setting 'display_error=0'.
> This setting hides errors from user but may send to him just a blank page.
>
> The proposed patch sends HTTP 500 response on errors instead of blank pages.
> The pages that already wrote something are not affectd.
>
> Any objections or additions?
>
> Thanks. Dmitry.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

Richard Lynch

19 years ago

On Wed, June 13, 2007 2:07 am, Dmitry Stogov wrote:

> Current time most PHP instalations use setting 'display_error=0'.
> This setting hides errors from user but may send to him just a blank
> page.
>
> The proposed patch sends HTTP 500 response on errors instead of blank
> pages.
> The pages that already wrote something are not affectd.
>
> Any objections or additions?

This sounds perfectly reasonable...

But I suspect some users might prefer a 404 or a customizable response
of some type...

At the risk of incurring the wrath of list members, perhaps yet
another php.ini configuration switch could be considered?...

I wouldn't hold up the 500 patch for long with this kind of
discussion, but it's worth taking a few minutes to consider, I think.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Dmitry Stogov

19 years ago

Configuaratin option make sense, but PHP already has too many configuration
options especialliy for error reprting.
I would like to avoid new ones.

Thanks. Dmitry.

Stanislav Malyshev

19 years ago

> Configuaratin option make sense, but PHP already has too many configuration
> options especialliy for error reprting.
> I would like to avoid new ones.

set_error_code(500) (or set_error_code(404)) might help?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

David Coallier

19 years ago

On 6/13/07, Stanislav Malyshev <stas@zend.com> wrote:

> > Configuaratin option make sense, but PHP already has too many configuration
> > options especialliy for error reprting.
> > I would like to avoid new ones.
>
> set_error_code(500) (or set_error_code(404)) might help?
> --

I am with set_error_code +1

> Stanislav Malyshev, Zend Products Engineer
> stas@zend.com  http://www.zend.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

Nicolas Bérard Nault

19 years ago

Returning 404 (or any other code other than 500) does not make sense. If an
user sees a Page not found error, he probably won't bother and won't come
back / delete his bookmark. On the other hand, if a search engine bot
stumbles upon one of these, the page is automatically erased from the index,
no questions asked. Off-hand, I can see these two consequences, on top of
not respecting the HTTP standard.

This seems obvious but am I missing something ?

On 6/13/07, David Coallier <davidc@php.net> wrote:

>
> On 6/13/07, Stanislav Malyshev <stas@zend.com> wrote:
> > > Configuaratin option make sense, but PHP already has too many
> configuration
> > > options especialliy for error reprting.
> > > I would like to avoid new ones.
> >
> > set_error_code(500) (or set_error_code(404)) might help?
> > --
>
> I am with set_error_code +1
>
>
> > Stanislav Malyshev, Zend Products Engineer
> > stas@zend.com  http://www.zend.com/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

Andrei Nigmatulin

19 years ago

On Wednesday 13 June 2007 21:45, Nicolas Bérard-Nault wrote:

> Returning 404 (or any other code other than 500) does not make sense. If an
> user sees a Page not found error, he probably won't bother and won't come
> back / delete his bookmark. On the other hand, if a search engine bot
> stumbles upon one of these, the page is automatically erased from the
> index, no questions asked. Off-hand, I can see these two consequences, on
> top of not respecting the HTTP standard.

At least for fastcgi SAPI code other than 500 does make sense, since most web
servers use 500 as "Backend unavailable" (connection refused). What if people
need to distinguish these two ?

> This seems obvious but am I missing something ?
>
> On 6/13/07, David Coallier <davidc@php.net> wrote:
> > On 6/13/07, Stanislav Malyshev <stas@zend.com> wrote:
> > > > Configuaratin option make sense, but PHP already has too many
> >
> > configuration
> >
> > > > options especialliy for error reprting.
> > > > I would like to avoid new ones.
> > >
> > > set_error_code(500) (or set_error_code(404)) might help?
> > > --
> >
> > I am with set_error_code +1
> >
> > > Stanislav Malyshev, Zend Products Engineer
> > > stas@zend.com  http://www.zend.com/
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > --
> > David Coallier,
> > Founder & Software Architect,
> > Agora Production (http://agoraproduction.com)
> > 51.42.06.70.18
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php

--
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take

Nicolas Bérard Nault

19 years ago

Hmm, maybe you're talking about 503, which is not exactly the same thing as
500.

Take a look at RFC 2616, section 10.

On 6/13/07, Andrei Nigmatulin <anight@eyelinkmedia.com> wrote:

>
> On Wednesday 13 June 2007 21:45, Nicolas Bérard-Nault wrote:
> > Returning 404 (or any other code other than 500) does not make sense. If
> an
> > user sees a Page not found error, he probably won't bother and won't
> come
> > back / delete his bookmark. On the other hand, if a search engine bot
> > stumbles upon one of these, the page is automatically erased from the
> > index, no questions asked. Off-hand, I can see these two consequences,
> on
> > top of not respecting the HTTP standard.
>
> At least for fastcgi SAPI code other than 500 does make sense, since most
> web
> servers use 500 as "Backend unavailable" (connection refused). What if
> people
> need to distinguish these two ?
>
>
> > This seems obvious but am I missing something ?
> >
> > On 6/13/07, David Coallier <davidc@php.net> wrote:
> > > On 6/13/07, Stanislav Malyshev < stas@zend.com> wrote:
> > > > > Configuaratin option make sense, but PHP already has too many
> > >
> > > configuration
> > >
> > > > > options especialliy for error reprting.
> > > > > I would like to avoid new ones.
> > > >
> > > > set_error_code(500) (or set_error_code(404)) might help?
> > > > --
> > >
> > > I am with set_error_code +1
> > >
> > > > Stanislav Malyshev, Zend Products Engineer
> > > > stas@zend.com  http://www.zend.com/
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > > --
> > > David Coallier,
> > > Founder & Software Architect,
> > > Agora Production (http://agoraproduction.com)
> > > 51.42.06.70.18
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> Andrei Nigmatulin
> GPG PUB KEY 6449830D
>
> Now I lay me down to sleep(3)
> Pray the OS my core to keep
> If I die before I wake
> Pray the Disk my core to take
>

--
Nicolas Bérard-Nault (nicobn@gmail.com)
Étudiant D.E.C. Sciences, Lettres & Arts
Cégep de Sherbrooke

Homepage: http://nicobn.googlepages.com

Andrei Nigmatulin

19 years ago

On Wednesday 13 June 2007 22:17, Nicolas Bérard-Nault wrote:

> Hmm, maybe you're talking about 503, which is not exactly the same thing as
> 500.
>
> Take a look at RFC 2616, section 10.

10.5.4 503 Service Unavailable

The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server.

This error have nothing to do with backend (gateway).

> On 6/13/07, Andrei Nigmatulin <anight@eyelinkmedia.com> wrote:
> > On Wednesday 13 June 2007 21:45, Nicolas Bérard-Nault wrote:
> > > Returning 404 (or any other code other than 500) does not make sense.
> > > If
> >
> > an
> >
> > > user sees a Page not found error, he probably won't bother and won't
> >
> > come
> >
> > > back / delete his bookmark. On the other hand, if a search engine bot
> > > stumbles upon one of these, the page is automatically erased from the
> > > index, no questions asked. Off-hand, I can see these two consequences,
> >
> > on
> >
> > > top of not respecting the HTTP standard.
> >
> > At least for fastcgi SAPI code other than 500 does make sense, since most
> > web
> > servers use 500 as "Backend unavailable" (connection refused). What if
> > people
> > need to distinguish these two ?
> >
> > > This seems obvious but am I missing something ?
> > >
> > > On 6/13/07, David Coallier <davidc@php.net> wrote:
> > > > On 6/13/07, Stanislav Malyshev < stas@zend.com> wrote:
> > > > > > Configuaratin option make sense, but PHP already has too many
> > > >
> > > > configuration
> > > >
> > > > > > options especialliy for error reprting.
> > > > > > I would like to avoid new ones.
> > > > >
> > > > > set_error_code(500) (or set_error_code(404)) might help?
> > > > > --
> > > >
> > > > I am with set_error_code +1
> > > >
> > > > > Stanislav Malyshev, Zend Products Engineer
> > > > > stas@zend.com  http://www.zend.com/
> > > > >
> > > > > --
> > > > > PHP Internals - PHP Runtime Development Mailing List
> > > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > > > --
> > > > David Coallier,
> > > > Founder & Software Architect,
> > > > Agora Production (http://agoraproduction.com)
> > > > 51.42.06.70.18
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > --
> > Andrei Nigmatulin
> > GPG PUB KEY 6449830D
> >
> > Now I lay me down to sleep(3)
> > Pray the OS my core to keep
> > If I die before I wake
> > Pray the Disk my core to take

--
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take

Uwe Schindler

19 years ago

Where is the propsed patch? I was thinking about a (not SAPI specific the
subject indicates!!!!) modification to the php-output parts that sends a
HTTP status "500" when a fatal error occurs and no output was yet send (SAPI
did not start the response). I think there is no need for a configuration
setting. A CGI program that crashes on startup creates error 500, a
servlet/JSP that does not startup creates error 500,... In principle SAPI
should return a FAILURE to the webserver from the handler function and set
the status code before. The webserver then generates the default error page.


-----
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

Dmitry Stogov

19 years ago

Oh, sorry. The patch was filtered :)
I am sendig it again.

It is sapi independent.

Thanks. Dmitry.

Stanislav Malyshev

19 years ago

> Oh, sorry. The patch was filtered :)
> I am sendig it again.
>
> It is sapi independent.

I think we could extend it by allowing people to specify the error code
(and maybe also error string - though not sure it's needed) - something
like set_error_code() function.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Hannes Magnusson

19 years ago

On 6/13/07, Stanislav Malyshev <stas@zend.com> wrote:

> > Oh, sorry. The patch was filtered :)
> > I am sendig it again.
> >
> > It is sapi independent.
>
> I think we could extend it by allowing people to specify the error code
> (and maybe also error string - though not sure it's needed) - something
> like set_error_code() function.

I thought the goal of the patch was to display an error page on things
like syntax errors?
in that case, set_error_code() would never be called..., even if it
would be called, why would you want to change the error code and into
what?

-Hannes

Stanislav Malyshev

19 years ago

> I thought the goal of the patch was to display an error page on things
> like syntax errors?

Sure, one of.

> in that case, set_error_code() would never be called..., even if it

Why not? PHP scripts often consist of dozens of files, and the fatal
error could happen in any of them beofre any outpus is produced, but
some code already had chance to run.

> would be called, why would you want to change the error code and into
> what?

I wouldn't. :) But I see some people here have some things they would
like to change there, so why not to help them?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Alex Kiesel

19 years ago

Dmitry Stogov schrieb:

> Hi,
>
> Current time most PHP instalations use setting 'display_error=0'.
> This setting hides errors from user but may send to him just a blank page.
>
> The proposed patch sends HTTP 500 response on errors instead of blank pages.
> The pages that already wrote something are not affectd.
>
> Any objections or additions?

Is there any change to change Apache(2)-Sapi dependent code, so that the
HTTP status is propagated to the Apache process and an ErrorDocument
will be triggered [1]?

Otherwise, the user still ends up with a blank page...

[1] http://www.thescripts.com/forum/thread644678.html

Regards,
-Alex

Dmitry Stogov

19 years ago

Apache-SAPI is effected by this patch too.
(patch is already committed)

Dmitry.