Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a webserver which serves content for a site, let's call it "domain.com". On that site, I have several PHP scripts that serve content. When someone browses to that site, everything works.

If I request, from within PHP (with Curl/Fopen), a URL on my own site (I'll call "domain.com/api/something.php?x=y", I get a timeout that the site could not be contacted. That only happens when I request that URL via PHP, not when called via the CLI. When I browse the URL from externally, that works.

On the server, I can "curl " or "wget ", and that works. I can use PHP to request pages externally hosted (google.com etc.), but I can not do it with pages hosted on my lighttpd config on the same server.

Is this familiar to anyone? Are there known parameters that could conflict with this?

share|improve this question
    
Is localhost configured to use some proxy? If you try "echo $http_proxy" on the server, does that return some proxy server? Or is PHP configured to use some proxy? –  Janne Pikkarainen Oct 29 '10 at 9:31
    
No proxy has been configured, neither on the server itself, nor in PHP. –  Mojah Oct 29 '10 at 14:11
    
Did you ever get this resolved? I have exactly the same configuration as you (Lighttpd, CURL, PHP) and exactly the same problem. I too have gone through all of the troubleshooting that you went through, and can't resolve the issue. –  Keith Palmer Feb 18 '11 at 18:06
add comment

2 Answers

up vote 1 down vote accepted

FIGURED IT OUT! By default, Lighttpd on FreeBSD is configured like this:

fastcgi.server = ( ".php" =>
                   ( "php-local" =>
                     (
                       "socket" => socket_dir + "/php-fastcgi-1.socket",
#                       "bin-path" => server_root + "/cgi-bin/php5",
                       "bin-path" => "/usr/local/bin/php-cgi",
                       "max-procs" => 1,
                       "broken-scriptfilename" => "enable",
                     )
                   ),

The key line being:

 "max-procs" => 1,

If you change it to, say, 50, it works fine. I'm assuming that it needs to fork off another process or something to make the CURL request, and can't because max-procs is set to 1 by default.

Change it, restart Lighttpd, works perfect. Yeah!

share|improve this answer
add comment

Can your own box correctly resolve the domain name you're using? If you're requesting files from www.domain.com, can you ping 'www.domain.com' from itself - Does it resolve the correct external IP that would receive when you ping 'www.domain.com' from an external connection.

I'm thinking:

1) The machine name is aliased in your /etc/hosts as 127.0.0.1 and your webserver isn't bound to the loopback address

2) What about load-balancers, are you using any that might cause routing issues when trying to route to itself

Andrew

share|improve this answer
    
#1) the box can resolve it correctly. In fact, a "wget <full url>" from the CLI works, but from within PHP it does not #2) ping also works, I don't think its resolving related #3) there are no load balancers or /etc/hosts that would bind my IP to something else –  Mojah Oct 29 '10 at 14:04
    
It must be related to your php.ini settings; did you re-use your old php.ini from your previous install or is this a new setup. –  Andrew Taylor Oct 29 '10 at 16:22
    
I donk't think it's PHP related. It works when requesting external URLs, just not those that are hosted locally. PHP.ini is a standard one, nothing special or custom. –  Mojah Oct 31 '10 at 19:15
    
Your PHP may not be 'custom' but there are a number of standard options which may limit what you can fopen and curl from PHP. You say the box can WGET from the CLI but not from PHP so that rules out DNS / ROUTING / Firewalls. I'd try creating a new test.php file that contains the bare minimum to prove your case, then, run it from the PHP-CLI (ie using PHP but not MOD_APACHE). PHP-CLI can be given a command line option to suppress php.ini. I'm fairly sure I could sort your problem in 10 minutes with some hands-on troubleshooting, it's just hard via SO. –  Andrew Taylor Nov 2 '10 at 13:48
    
Agreed, it's not easy this. I had already tried what you mention: a sample PHP script works via the CLI, not when called via the browser. So I suspect it's a lighttpd/fastcgi problem, not necessarely a PHP one. Because the problem only exists when called via the lighttpd service. –  Mojah Nov 3 '10 at 14:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.