On Wed, Jun 25, 2014 at 5:25 PM, Johannes Schlüter <johan...@schlueters.de> wrote:
> On Wed, 2014-06-25 at 16:32 +0200, Ferenc Kovacs wrote: > > > > > We can't set 500 response code if HTTP headers were already sent. > > > > > > > we have the !SG(headers_sent) check for that, and I'm not proposing to > > remove that(albeit I think that we could handle the special scenario, > > when > > the only output is generated by the error, but that is a separate > > topic). > > > > > I believe this causes some inconsistency, sometimes status code is > changed, sometimes not. Uncertain which is worse - wrong code or harder > to predict behavior. > > you mean it would be inconsistent if we would signal the error with a http 500 when it is technically possible (we haven't sent out the headers) versus when the error happened after the headers were already sent? if we consider this as inconsistency, we are already inconsistent, and I'm not sure what would be the consistent alternative: not sending http 500 at all? but as I mentioned I'm not really interested changing the headers already sent scenario (as there isn't much we could do), but I do think that the current behavior about only setting the response code to 500 if display_errors is disabled is questionable. I would like to know if you think that changing this is out of the question or not, and if we would change it, should it happen a minor or a major version. I also think it would make sense to document the current behavior, I couldn't find anything regarding this in the docs. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
