ID: 18824
User updated by: bugs.php.net@mnot.net
Reported By: bugs.php.net@mnot.net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: unknown (maybe FreeBSD?)
PHP Version: 4.2.2
New Comment:
No, actually I missed it ;)
All that I'm proposing is that the default status code be changed from
200 to 500 *if* a fault is encoutered. If the script has changed it in
the meantime, so be it. I definately don't want to remove the
flexibility to express semantics in the language; only create the
proper defaults based on known conditions.
I can think of many real-world situations where the current behaviour
is broken; e.g., CDNs like Akamai will cache erroneous content if it
comes with a 200, but do the right thing if they see a 500.
Tis late (at least here). Obviously, you don't agree with my arguments
here, so I'm happy to leave this as is, for consideration by others.
Cheers,
Previous Comments:
------------------------------------------------------------------------
[2002-08-09 04:09:24] rasmus@php.net
That's fine, and trust me, I have read Roy's papers, but you nicely
avoided the realworld example I gave you which showed a perfect case
where the application author needs control over when to make something
a server error and when not to. I fully agree that people should write
decent error handling functions that do something intelligent, but I do
not believe in removing flexibility from PHP and forcing every error to
generate a 500.
------------------------------------------------------------------------
[2002-08-09 03:49:44] bugs.php.net@mnot.net
Please see Roy Fieldings' dissertation:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
And comments by Henrik Frystyk Neilsen:
http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&F=&S=&P=33153
Basically, there is no "Application Layer" vs. "Server Layer"; HTTP is
an application layer protocol, and any differentiation between the
software that serves the request and the software that implements the
logic to generate the content is in the mind of the developer only.
This point has been debated elsewhere ad nauseum, but the people who
architected the Web in the first place all agree that HTTP status codes
should carry this kind of information.
------------------------------------------------------------------------
[2002-08-09 03:42:21] rasmus@php.net
I still don't agree that this should be a default thing. An
application level error is quite different from a server-level error.
Most production sites should be redirecting all errors to a log file or
some other mechanism. There can be runtime errors that occur that do
not significantly impact users. In that sense I do not believe
application level errors should be extended to the client. Perhaps an
argument can be made for fatal php initialization errors that occur at
the interface between the server and PHP.
For example, how about a simple redirection script which sends a
location header and either a 301 or a 302. Some logging code after the
redirect fails for some reason. In normal operation, the user still
gets redirected, but in your scenario this becomes a 500 and the script
no longer works.
------------------------------------------------------------------------
[2002-08-09 03:01:45] bugs.php.net@mnot.net
IMP buffers, as does any other application using HTTP:Compress.
> Also, consider that errors generally occur after some
> valid content has been generated, and not sending this
> in a valid response would make it considerably harder to
> debug things.
A 500 response can have a body just as easily as a 200 can.
> If someone wants this functionality in buffered mode,
> they could easily do it with their own error handling
> function.
It's not the person writing the application who would necessarily want
this functionality; it's the consumer of the application. The idea is
to be compatible with the Web architecture, and that means honoring the
semantics of the protocols.
Cheers,
------------------------------------------------------------------------
[2002-08-09 02:55:51] rasmus@php.net
No, buffering is not that common. But even so, having the http status
change depending on buffering would be quite inconsistent and would
likely confuse the heck out of people. Also, consider that errors
generally occur after some valid content has been generated, and not
sending this in a valid response would make it considerably harder to
debug things.
If someone wants this functionality in buffered mode, they could easily
do it with their own error handling function.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/18824
--
Edit this bug report at http://bugs.php.net/?id=18824&edit=1