Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain proposaltech.com does not designate 66.94.236.17 as permitted sender)
To: internals@lists.php.net
In-Reply-To: <1338526836.9578.94.camel@inspiron>
References: <1338526062.9578.83.camel@inspiron>
	 <1338526836.9578.94.camel@inspiron>
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 01 Jun 2012 09:50:09 -0700
Message-ID: <1338569409.27086.36.camel@inspiron>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Was php bug (IMHO).  Have fix.  Re: Bad eval() leading to response
 code 500
From: truth@proposaltech.com (Todd Ruth)

eval() does indeed set the response code to 500 upon failure.
Is that a bug?  I'll file a report because I don't believe
leaving the response code at 500 is consistent with the
statement from the php.net page about eval():

"If there is a parse error in the evaluated code, eval() 
returns FALSE and execution of the following code continues normally."

I don't think leaving the the response code at 500 is consistent
with "continues normally".  I believe the fix is one line, adding
"&& EG(current_execute_data)->opline->extended_value != ZEND_EVAL"
to the "if" clauses before setting the error header in main.c
at line 1132.

In case anyone finds my post from last night while doing a search 
of the archives, I'll explain more below and answer my question 
about debugging.

What I didn't realize at the time of my post last night is that 
browsers don't mind receiving a 500 as long as everything else 
looks good.  For example, the following web page:

<?php
eval('0+');
print "hello world\n";
?>

looks fine in a browser so I assumed (oops!) that it was returning
code 200.  If you try doing a wget on that example, it complains
about the response code 500.  (My big ugly application uses AJAX
and the 500 caused my AJAX framework to reject the page.)

Other than the code 500, everything seems to proceed normally.
All of the other code is executed normally.  The content of the
web page is normal and is displayed well in a browser unless you
have something checking for unhappy response codes.

The answer to my question about watching the headers in the
debugger turned out to be pretty easy:
watch sapi_globals.sapi_headers
watch sapi_globals.sapi_headers.http_response_code
It would not have been so simple with ZTS on.  (In that case,
the TSRM macros come in to play.)