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.)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
