|   | php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login | 
| 
  [2002-09-15 12:58 UTC] msopacua at idg dot nl
 Curl cannot resolve hosts in php, while it can on the command line, same curl version/package.
Testscript:
<?php
$ch = curl_init('http://bugs.php.net');
$result = curl_exec($ch);
if(!$result)
{
	print(curl_error($ch) . ' using ' . curl_version());
}
else
{
	print($result);
}
?>
Results:
msopacua@server ~
$ /php/bin/php -f ./test_curl.php
Couldn't resolve host 'bugs.php.net' using libcurl 7.9.8 (OpenSSL 0.9.6c)
msopacua@server ~
$ /weblib/local/bin/curl http://bugs.php.net/ >/dev/null
  % Total    % Received % Xferd  Average Speed          Time             Curr.
                                 Dload  Upload Total    Current  Left    Speed
100  4181    0  4181    0     0   9374      0 --:--:--  0:00:00 --:--:-- 21577
msopacua@server ~
$ /weblib/local/bin/curl --version
curl 7.9.8 (i386-pc-bsdi4.1) libcurl 7.9.8 (OpenSSL 0.9.6c)
Results are the same for cli and apache static sapi.
I have manually set HAVE_RES_SEARCH, HAVE_GETHOSTBYADDR_R and HAVE_GETHOSTBYNAME_R in main/php_config.h after configuring, to try and work around the issue, to no avail.
Configured php using:
CFLAGS='-O0 -fno-omit-frame-pointer -mcpu=pentium' \
./configure \
        --prefix=/php \
        --enable-debug \
        --enable-cli \
        --with-apache=../apache_1.3.26 \
        --enable-magic-quotes \
        --disable-short-tags \
        --enable-bcmath \
        --enable-calendar \
        --enable-ctype \
        --enable-ftp \
        --enable-mailparse \
        --enable-mbstring \
        --enable-sockets \
        --enable-tokenizer \
        --enable-xslt \
        --enable-inline-optimization \
        --with-gettext=/weblib/local \
        --with-pear \
        --with-openssl=/weblib/local \
        --with-zlib-dir=/weblib/local \
        --with-zlib=/weblib/local \
        --with-curl=/weblib/local \
        --with-gd=/weblib/local \
        --with-jpeg-dir=/weblib/local \
        --with-png-dir=/weblib/local \
        --with-freetype-dir=/weblib/local \
        --with-iconv=/weblib/local \
        --with-mhash=/weblib/local \
        --with-mysql=/mysql \
        --with-pgsql=/pgsql \
        --with-pspell=/weblib/local \
        --with-expat-dir=/weblib/local \
        --with-xslt-sablot=/weblib/local \
        --with-dom=/weblib/local \
        --with-dom-xslt=/weblib/local \
        --with-dom-exslt=/weblib/local \
        --with-expat-dir=/weblib/local \
        --with-sablot-js=/weblib/local \
        --with-imap=/weblib/local \
        --with-zip=/weblib/local \
        --with-pic
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits             | |||||||||||||||||||||||||||
|  Copyright © 2001-2025 The PHP Group All rights reserved. | Last updated: Thu Oct 30 23:00:01 2025 UTC | 
I've debugged this further and it seems to be a more general issue with resolver functions. gethostbyname() does the exact same thing as does Apache, when run in 'HostnameLookup' mode - they only find host in /etc/hosts and connect 'somewhere', which is not on port 53 anywhere on my system. A script: <?php print gethostbyname('bugs.php.net'); ?> with a breakpoint at dns.c:194 shows that 'hp' is NULL and h_errno is 2 (TRY_AGAIN). When the exact same code is run as a normal program, all is well, so somewhere in the php/apache combination, something goes wrong with gethostbyname and related functions, which apparently affects extension modules and apache behavior. I'll test HEAD later on.