php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #41342 PHP says syntax errors are 200 OK
Submitted: 2007-05-09 23:11 UTC Modified: 2014-08-08 13:13 UTC
Votes:7
Avg. Score:5.0 ± 0.0
Reproduced:7 of 7 (100.0%)
Same Version:1 (14.3%)
Same OS:0 (0.0%)
From: defenestrator at gmail dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 5.2.2 OS: FreeBSD
Private report: No CVE-ID: None
 [2007-05-09 23:11 UTC] defenestrator at gmail dot com
Description:
------------
When there is a syntax error in a PHP file, PHP sends back a 200 OK response without any caching headers. This results in browsers such as IE or Opera caching the resulting error, which can hinder debugging in some cases. For example, an XMLHttpRequest to a faulty script can't be easily force-refreshed from a browser.

I'd prefer for PHP to produce a 500 error in this case. Alternatively, if you must produce a 200, then sending some headers to inhibit caching will solve the problem as well.

Reproduce code:
---------------
<?<?>

Expected result:
----------------
HTTP/1.1 500 Internal Server Error
...
Content-Length: 144
Content-Type: text/html

<br />
<b>Parse error</b>:  syntax error, unexpected '<' ...

Actual result:
--------------
HTTP/1.1 200 OK
...
Content-Length: 144
Content-Type: text/html

<br />
<b>Parse error</b>:  syntax error, unexpected '<' ...

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-11-30 00:02 UTC] defenestrator at gmail dot com
I need display_errors on in development environments, which is where the 200 OK response is causing the inconvenience for me in the first place. If I make an AJAX request to a PHP file that produces an error, then I can correct the error but any further requests to the same URL are pulled out of the browser cache, with no direct way to refresh it. Many workarounds exist but none should be necessary.

There really isn't any benefit to *not* producing a 500 error here.
 [2009-03-17 18:45 UTC] php at plummer dot us
I just want to be able to notify people of errors. With syntax errors, I can't use php code to do so and the web server doesn't know there's been a problem when a 200 response is returned so I can't use its error reporting capabilities. Basically it violates the http rfc to return a 200 on an error response.
 [2009-08-27 11:55 UTC] steffen at steffen-gebert dot de
I have display_errors off and I also get code 200 (on syntax errors, undefined functions, ..).

Please.. really sent 500 here!
 [2010-02-03 10:04 UTC] jani@php.net
Already happens in correct conditions. (display_errors off, headers not sent by the time error happens and if status was 200 before the error)
 [2010-02-08 02:36 UTC] defenestrator at gmail dot com
Having display_errors off should not be part of the correct conditions. I have display_errors on in my development environment, and I want a 500 code in that situation. Getting a 200 code causes errors to be cached, and if there's such an error in an AJAX request, then it can't be easily refreshed in some browsers. I have to test things in a lot of browsers, so it would be great if I could get a 500 here.
 [2014-08-08 12:59 UTC] bjoerndietz at gmx dot de
I'm not sure if this is good practise or not, but many php-based webservices use the HTTP response codes to declare if the process invoked has been successful or not. For those it can be a painful experience looking for a possible error behaviour while only dealing with the 200 response (yes, the clients should look at the additional data returned if there are any).

Therefore there should be some way to configure the HTTP response code for these situations. I'd expect a 500 error, too.
 [2014-08-08 13:13 UTC] tyrael@php.net
-Package: Feature/Change Request +Package: *General Issues
 [2014-08-08 13:13 UTC] tyrael@php.net
duplicate of https://bugs.php.net/bug.php?id=50921
please check out the discussion and the reasoning for the current behavior there.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Aug 16 10:05:45 2022 UTC