Bug #69636 [Opn->Wfx]: putenv() persits in a cURL request to same server.

From: Date: Sun, 17 May 2015 11:59:28 +0000
Subject: Bug #69636 [Opn->Wfx]: putenv() persits in a cURL request to same server.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-192710@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69636&edit=1 ID: 69636 Updated by: ab@php.net Reported by: jake dot zatecky at gmail dot com Summary: putenv() persits in a cURL request to same server. -Status: Open +Status: Wont fix Type: Bug Package: PHP options/info functions Operating System: Windows 7/Windows Server 2008 PHP Version: 5.6.8 Block user comment: N Private report: N New Comment: Here we go. putenv()/getenv() rely on C runtime and are process wide. The list of variables set by putenv() is maintained internally, those variables are then cleared on request shutdown. With a thread safe SAPI, every request is served concurrently within the same process. Thus, the environment of the first request isn't cleared yet while the second request starts. But both are served within the same process, both are running simultaneously, so they share the environment. Thanks. Previous Comments: ------------------------------------------------------------------------ [2015-05-15 19:54:31] ab@php.net @jake, sapi/apache utilizes thread safety, sapi/cli and sapi/fcgi not necessarily. But thead safety is probably be the exact difference. That your CLI hangs must be some config issue, the built-in server shouldn't fail on such simple case. The key point of #69033 is that ENV isn't cleared within the same process. I'll test this with Apache then. Thanks. ------------------------------------------------------------------------ [2015-05-15 07:16:18] jake dot zatecky at gmail dot com I was using an Apache 2.4 server. I assume that the built-in web server would not be sufficient because it can only process a single request at a time without deadlocking. That is to say, I tried testing with the built-in server, but it hangs when I attempt to cURL on the same port with callee.php. It should be noted that the test I had can be misleading, as a failed curl_exec could also output false (easily remedied by outputting something additional on callee.php). It's also worth noting that I additionally tested this on 5.5.25 and got the same result. The patch in bug #69033 was included in 5.5.22. ------------------------------------------------------------------------ [2015-05-15 06:29:20] ab@php.net Hm, this should have been fixed already, see bug #69033. Anyway I cannot reproduce this with the built-in web server. Is there something special one needs to care about? Which server? Thanks. ------------------------------------------------------------------------ [2015-05-14 23:20:45] jake dot zatecky at gmail dot com Description: ------------ http://php.net/manual/en/function.putenv.php The PHP doc states that when using putenv(), "The environment variable will only exist for the duration of the current request." I have found that if one uses this function and then invokes a cURL request targeting the same server, this environment change persists. Presumably this is because we're using the same request? The same cannot be said if I utilize the $_ENV superglobal. In the test script below, the TEST environment variable will persist for the cURL request. There appears to be no way to reset all environment variables to their original state, short of tracking each key and setting each value before making the request. Setting several of the cURL options also appears to have no affect. Test script: --------------- <?php // caller.php // ------------------ putenv("TEST=This persists on cURL request."); $url = "http://127.0.0.1/callee.php"; $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); echo curl_exec($ch); // callee.php // ------------------ var_dump(getenv("TEST")); Expected result: ---------------- getenv("TEST") returns false Actual result: -------------- getenv("TEST") returns "This persists on cURL request." ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=69636&edit=1

« previous php.bugs (#192710) next »