php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #69636 putenv() persits in a cURL request to same server.
Submitted: 2015-05-14 23:20 UTC Modified: 2015-05-17 11:59 UTC
From: jake dot zatecky at gmail dot com Assigned:
Status: Wont fix Package: PHP options/info functions
PHP Version: 5.6.8 OS: Windows 7/Windows Server 2008
Private report: No CVE-ID: None
View Developer Edit
 [2015-05-14 23:20 UTC] 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."

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-05-15 06:29 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-05-15 06:29 UTC] 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-15 07:16 UTC] jake dot zatecky at gmail dot com
-Status: Feedback +Status: Open
 [2015-05-15 07:16 UTC] 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 19:54 UTC] 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-17 11:59 UTC] ab@php.net
-Status: Open +Status: Wont fix
 [2015-05-17 11:59 UTC] ab@php.net 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC