Bug #77841 [NEW]: http_response_code returns the HTTP response code from the CLI
| From: | krowe dot dev at gmail dot com | Date: | Wed, 03 Apr 2019 21:28:07 +0000 |
| Subject: | Bug #77841 [NEW]: http_response_code returns the HTTP response code from the CLI | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-220305@lists.php.net to get a copy of this message | ||
From: krowe dot dev at gmail dot com
Operating system: ALL
PHP version: Irrelevant
Package: HTTP related
Bug Type: Bug
Bug description:http_response_code returns the HTTP response code from the CLI
Description:
------------
The manual page for the http_response_code function states:
"FALSE will be returned if response_code is not provided and it is not
invoked in a web server environment (such as from a CLI application)."
Which is the way this behaves when http_response_code() has not been
called already. However, if you call http_response_code() and pass it a
value, further calls to http_response_code() without a value will return
the value you've set even from a CLI environment.
This side effect could be a issue with any code that is written to work
when called from any environment using this function to determine
environment type. This issue could instantly be fixed by rewording the
manual to more accurately describe the behavior of this function. IMHO
PHP really *SHOULD* provide a definitive way to determine if we should
be rendering HTML or plain text and, if this worked as advertised, it
would fit that use case perfectly well. As it is, it does work but only
if you can guarantee that nothing else is mucking about with the
response code. This makes it unreliable to use in situations where the
response code may have been set.
This problem is easily worked around by making sure that you store the
value of http_response_code() before you call it with any parameters.
Still, this is not the expected behavior given the wording of the manual
and it also makes this function less useful as a simple check to
determine if the script is being ran from a CLI environment.
I've verified that this is the case on PHP version 5.6.29 and is still a
bug in version 7.2.2 . I have not checked any other versions.
Test script:
---------------
<?php
// $is_cli is properly set to FALSE even though the response code
defaults
// to 200 in all environments. However, this will no longer work after
the
// next call to http_response_code().
$is_cli=http_response_code();
var_dump($is_cli);
// Calling http_response_code() with a status code causes the bug to
occur.
http_response_code(300);
// This is the bug. $is_cli should be FALSE if this is being ran from
the CLI.
// In a web environment, it should now be 300.
$is_cli=http_response_code();
var_dump($is_cli);
Expected result:
----------------
Expected result in a CLI environment:
bool(false)
bool(false)
Expected result in a web environment:
int(200)
int(300)
Actual result:
--------------
Actual result in a CLI environment:
bool(false)
int(300)
Actual result in a web environment:
int(200)
int(300)
--
Edit bug report at https://bugs.php.net/bug.php?id=77841&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=77841&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=77841&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=77841&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=77841&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=77841&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=77841&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=77841&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=77841&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=77841&r=support
Expected behavior: https://bugs.php.net/fix.php?id=77841&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=77841&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=77841&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=77841&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=77841&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=77841&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=77841&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=77841&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=77841&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=77841&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=77841&r=mysqlcfg