You are assuming that PHP buffers all output before sending anything.  That is an incorrect assumption.  A fatal script error can occur long after the HTTP response headers have been sent.

So is the correct status code output if the response is buffered? AFAIK a fair number of PHP applications use output buffering these days, so it would be useful to take advantage.

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.

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,

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.  

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.

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.  

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,

There is one huge, practical problem with the 500 responses -- IE/Win's canned error messages. Most people have not turned them off; many don't even know how. Getting the PHP error messages replaced by an obfuscated Microsoft notice will have a very, very high WTF factor for a lot of users.

That said, there is no doubt that a tutorial like "HTTP for PHP Developers" would be a very useful part of the PHP manual. Status codes and, for example, the IMS negotiation mechanism are among the worst understood aspects of this trade.

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

Good point. 
A more rigorous implementation would understand that 'after the redirect' means the response is complete and further errors are not HTTP level errors and so should not modify the response - status, headers or other bits.

It is unreasonable to expect the world to change to recognize these subtle points - either server frameworks or authored scripts - but knowing the issue exists can help future implementations of both.