why do we not set http 500 for errors when the display_error is enabled

On Wed, Jun 25, 2014 at 4:32 PM, Rowan Collins rowan.collins@gmail.com
wrote:

Chris Wright wrote (on 25/06/2014):

I don't believe this is the case with any browser we might still be

reasonably expected to support. The browser generic error pages are
only displayed when there is no body content or a content-type it
doesn't understand.

Internet Explorer's "friendly error messages" are shown in preference to
any content smaller than a certain number of bytes (I can't remember the
exact threshold, but you will find plenty of minimal error pages padded out
with garbage comments as a workaround).

I've just had a quick look around online, and can't see anything saying
that this "feature" was removed in more recent versions. In fact, I just
did a quick test in IE11, and a page returning HTTP 500 and containing the
text "Done." is indeed replaced with the default error page. :(

we can't(and shouldn't) try to pad the response, as it could be any format,
not just html.
but I do think that we could expect the developer to be able to use the
view source functionallity to see the "true" output when presented with the
generic IE error page.
and this feature of ours breaks the semantic meaning of the http response
code and causes problems for those using any other browser than IE.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Chris Wright wrote (on 25/06/2014):

I don't believe this is the case with any browser we might still be
reasonably expected to support. The browser generic error pages are
only displayed when there is no body content or a content-type it
doesn't understand.

Internet Explorer's "friendly error messages" are shown in preference to any
content smaller than a certain number of bytes (I can't remember the exact
threshold, but you will find plenty of minimal error pages padded out with
garbage comments as a workaround).

I've just had a quick look around online, and can't see anything saying that
this "feature" was removed in more recent versions. In fact, I just did a
quick test in IE11, and a page returning HTTP 500 and containing the text
"Done." is indeed replaced with the default error page. :(

I tested briefly on my machine before sending the previous mail, but
it looks like I have the option set as outlined in the KB article
Ferenc linked - sorry for the misinformation.

Given this apparent variation/unpredictability, having another ini
setting to control the behaviour is possibly not a bad idea?

I see. I assume this is related to
http://support.microsoft.com/kb/294807
where by default IE shows pretty but generic message for non-2xx messages
if the response content length is less than or equal to a specific
threshold(512 bytes for 500 errors for example).
I don't think that it was a good idea to patch our error handling for the
sake of an usability feature only present in one browser.

Don’t other browsers do this as well? I believe Chrome and Firefox do, at
least for 404 errors.

I could only check chrome, safari and firefox on my mac, but all of those
properly show the expected output(123) for
<?php
header('HTTP/1.1 500 Internal Server Error');
echo "123";

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Wed, Jun 25, 2014 at 5:25 PM, Johannes Schlüter johannes@schlueters.de
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