Description:
------------
I do a curl to an url that runs a script on my server:

curl 'https://www.mydomain.com' -H 'accept-encoding: gzip, deflate, sdch, br' -H 'accept-language: en-US,en;q=0.8,ca;q=0.6,es;q=0.4,it;q=0.2,fr;q=0.2,pt;q=0.2,de;q=0.2' -H 'upgrade-insecure-requests: 1' -H 'authorization: Basic XXXXXXXX' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'cache-control: max-age=0' -H 'authority: www.mydomain.com' -H 'cookie: [.....]' -H 'referer: https://www.mydomain.com/whatever' -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36' --compressed

And I get:

* GnuTLS recv error (-110): The TLS connection was non-properly terminated.
* Closing connection 0

before any header (or anything for that matter) is received.

The request is not even logged into Apache's access log on the server, nor any error logged to error_log.


No matter what my PHP code does and how huge an error it may contain, that is NEVER, EVER an acceptable outcome.



I have figured out that the error is somehow triggered by this function:


function fetch_product_dependencies($productid, &$dependency_list)
{
        if (!is_array($dependency_list["$productid"]))
        {
                return array();
        }

        $list = array();
        foreach ($dependency_list["$productid"] AS $subproductid)
        {
                // only traverse this branch if we haven't done it before -- prevent infinte recursion
                if (!isset($list["$subproductid"]))
                {
                        $list["$subproductid"] = $subproductid;
                        $list = array_merge(
                                $list,
                                fetch_product_dependencies($subproductid, $dependency_list)
                        );
                }
        }

        return $list;
}


The way I have figured that out with absolute certainty is by bisection, by putting a die("some output") statement before calling the function (exits and outputs "some output") and then moving it after the call to the function (reproduces the issue).

Expected result:
----------------
Either there is some error in my code or there isn't.

Either way, and no matter what my code does, php must always produce a valid HTTP response, be it an error or OK response, with or without content. It can't, under any circumstances, violate the protocol and/or fail to respond completely, or cause Apache to do so.

Also, the request must always be logged to Apache's access log (if Apache is configured to do so). Nothing in PHP can ever cause a request to not be logged at all.

Actual result:
--------------
The output of curl shows that the server fails to return a valid HTTP response. Apparently it closes the connection abruptly, violating even the TLS protocol.

I guess PHP is crashing or something.