Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


please provide a sample script to illustrate the problem

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

The error is real except this guy has the wrong script.
I have the same problem - this is the script:

$method = "ssl://";
$host = "myserver.com"; 
$port = 443; 

$fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30); 

I get the error:
Warning: fsockopen(): no SSL support in this build 

AND SSL is loaded in php. Its a bug I patch on windows, but need one for linux

The same is seen here with php 4.3.6 freshly compiled on Debian / Linux.  Configure command is "./configure --enable-bcmath --with-openssl=/usr/local/openssl --with-mysql --with-apxs=/usr/bin/apxs --prefix=/usr/local"

This bug persists through reloads of apache; apache version is 1.3.26.  With so many people obviously affected by this PHP bug across multiple platforms, I'm concerned that the answer from PHP seems to be "it's not a PHP problem" promptly followed by marking threads as bogus.

--Scott!

You must build the openssl statically to use this feature.
There is a static version for windows, provided by Emini, who are also responsible for our win32 snapshots:
http://ftp.emini.dk/pub/php/win32/openssl/

We won't fix this in PHP 4, but it has already been fixed in PHP 5 (you can load openssl dynamically in PHP 5).

Err, I obviously was reading the odd-one-out comment.
Restoring status.

Somehow find it childish - will not fix it? What does this mean - I should migrate to PHP5 only because you find this not important enough. Pls reconsider this - I saw an hour ago that there are other fixes poping up in snaps.php.

It's a "Won't fix" for PHP4 because it requires a *significant* rewrite of the socket transport layer.  As any responsible developer knows, you don't make massive changes to a stable branch of code, that's how you introduce bugs.  You don't want bugs do you?

It's also a "Won't fix" because it does work in PHP4 if you simply follow the instructions:

For Linux: Compile OpenSSL support in staticly rather than as a shared module.  ./configure --with-openssl     rather than     ./configure --with-openssl=shared

For Windows: Use the alternate php4libts.dll provided at http://ftp.proventum.net/pub/php/win32/misc/openssl/ 

Creating a drama out of being "forced" to move to PHP5 to get ssl sockets to work seems...well... childish is a good word isn't it?

well there must be more than just forgotten ssl support.

i have php compiled with: '--with-openssl' and still if i do a fsockopen i end up with no socket AND a success message. if this is not a bug what else would be one?

i do:

$fp = fsockopen("http://www.webseite.com", 80, $errno, $errstr, 4);
if(!$fp){
  // this will echo the errorno: 0 and success message :p
   echo "$errstr ($errno)<br />\n";
}else{
  // stuff
}

Script output:
Warning:  fsockopen() [function.fsockopen]: php_network_getaddresses: getaddrinfo failed: Name or service not known in /www/htdocs/.... on line ...

Warning:  fsockopen() [function.fsockopen]: unable to connect to http://www.website.com:80 in /www/htdocs/.... on line ...

Success (0)

System is a Suse Linux / PHP 4.3.1

same script works on windows

and no i do not upgrade to php5 just for the taste of it :p
so me too would vote for a fix!


any comments welcome. thanks for doing php(4) :-)

--disable-ipv6 when you configure.

http://www.webseite.com is not a hostname.
http://www.webseite.com is a remote resource URL.
www.webseite.com is a hostname.

You are using the function incorrectly.

well little stupid me! i would recommend then to strip all the comments in the docs that contain resource url's instead of hostnames :-p

for some reason i think it is like making jokes. udp:// is oke, ssl:// yes, http:// makes it a 'thing'... i might use tcp:// instead as http is unknown to fsockopen? ok at least windows understands me...

ok i am just picking the details now ;)

thanks for clearify that!! please make a note into the manuals! :-)

I can see the confusion and will take a look at rewording some of the documentation.

http://, ftp://, gopher://, nntp://, etc... These all describe application layer protocols (known in PHP as wrappers).
See Also: http://www.php.net/wrappers


tcp://, udp://, unix://, udg://, ssl://, tls://, etc... describe network layer protocols (also referred to as socket transports).
See Also: http://www.php.net/transports

fopen() (and family) work with wrappers, while fsockopen() only works with transports.

When you use fopen('http://...', 'r') to open a remote resource URL.  PHP creates a socket connection to the specified host and caries on an entire conversation with the remote server (asking for a specific document, passing authentication parameters, user-agent, negotiating content encoding, etc...).

When you use fsockopen('tcp://hostname', 80) to open a connection to a remote listener, PHP creates the socket connection as before, but then stops, leaving the matter of application layer communication up to your script.

If you're interrested in more detail, google for "ISO Model" and read up about the differences between the layers.