Re: Re: why do we not set http 500 for errors when the display_error is enabled
| From: | Ferenc Kovacs | Date: | Wed, 25 Jun 2014 17:52:12 +0000 |
| Subject: | Re: Re: why do we not set http 500 for errors when the display_error is enabled | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75080@lists.php.net to get a copy of this message | ||
On Wed, Jun 25, 2014 at 6:58 PM, Florian Anderiasch <ml@anderiasch.de>
wrote:
> On 25.06.2014 17:39, Rowan Collins wrote:
> > Andrea Faulds wrote (on 25/06/2014):
> >> On 25 Jun 2014, at 15:32, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> >>
> >>> 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.
> >
> > Firefox and Chrome only show the default message if the response length
> > is ZERO bytes. Even the 26-byte response generated by empty content
> > going through gzip buffering appears to be enough for them both to show
> > the "real" output (in that case, a blank page).
> >
> > So it really is just IE that has this notion of the error message having
> > to be "long enough".
>
> It might be cache settings, but my Chromium definitely does not show a
> "default message" if I get a 204 with zero bytes, it keeps displaying
> the old content (if the url is the same). Developer Tools of course show
> this, but not the actual contents of the browser tab.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
that is a special case, and that is how it should be handled:
http://www.ietf.org/rfc/rfc2616.txt
If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent's active document view, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent's active view.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu