✋ anybody could review it or start a discussion ??

PD: I can start it later in internals if necessary !!

So I think this needs an RFC because it changes the way how CLI treats header function. I can see your use case but as can be seen in the issue, there is already one objection to it (note about throwing exception instead) so that alone shows there should be probably RFC.

Also changing behaviour is in some way a BC break as you actually needed to change one of the standard test. This would be still acceptable for minor version IMO but it should not state there is no BC break at all.

What about to test these functions as well:

• http_clear_last_response_headers
• http_get_last_response_headers
• http_response_code
• session_get_cookie_params
• session_set_cookie_params
• ob_end_flush

We are using the core header_handler that is well tested, we only add tests for CLI.

http_clear_last_response_headers() and http_get_last_response_headers() use the headers received via the HTTP wrapper, that we don't touch or use in this PR.

http_response_code() curiously is working in CLI. It's later used in the send_headers_handler that we don't use in CLI, and it's the job of the framework to manage the response code and any HTTP/ header.

<?php
ob_start();
echo PHP_SAPI . PHP_EOL;
http_response_code(400);
echo http_response_code();
/* return
cli
400
*/

session_set_cookie() and session_get_cookie() also work with CLI. And it's used by setcookie(), that it's tested in the PR.

<?php
ob_start();
echo PHP_SAPI . PHP_EOL;
session_set_cookie_params([
 'lifetime' => 600,
 'path' => '/',
 'domain' => 'example.com',
 'secure' => true,
 'httponly' => true,
 'samesite' => true
 ]);
 
 
var_dump(session_get_cookie_params());
/* return 
cli
array(6) {
 ["lifetime"]=>
 int(600)
 ["path"]=>
 string(1) "/"
 ["domain"]=>
 string(11) "example.com"
 ["secure"]=>
 bool(true)
 ["httponly"]=>
 bool(true)
 ["samesite"]=>
 string(1) "1"
}
*/

ob_end_flush() work like always, but in CLI is sent to the STDOUT without headers.
We don't want that, well we can play with the ob_start() callback to find a solution.
And here start another problem that we need to investigate, simplify data stream request and response from CLI. But that need an RFC.

http_response_code() curiously is working in CLI. It's later used in the send_headers_handler that we don't use in CLI, and it's the job of the framework to manage the response code and any HTTP/ header.

Wouldn't it better to create a full CLI mirror for every "http"-like function to not get back to another PR/RFC when you want to touch another aspect of the servers?
Some kind of drivers: http for web, in-memory for CLI. Like phpinfo() does, but more abstract