TYPO3 Core

What PHP version are you using? We know (and there is bug #16081 filed for ut), that 4.1 and 4.2 don't accept a parameter. In this case not only the hostname, but all of the info is return.

In your case php_uname('n') should (using PHP 4.3 or 5.x) return "infong".

BTW, the check with === is correct (see PHP docs).

I'm using PHP version 4.4.2.

It's running on a shared webserver of 1&1, so I have no influence on the installed version numbers.

Is there any workaround for the meantime?

After the mentioned warning of the gethostbyaddr() function there is displayed another warning message:

Warning: Cannot modify header information - headers already sent by (output started at /homepages/11/d92013368/htdocs/typo3/t3lib/class.t3lib_htmlmail.php:274) in /homepages/11/d92013368/htdocs/typo3/typo3/sysext/cms/tslib/class.tslib_fe.php on line 2767

Sorry for my poor knowledge of php, I have only some little php knowledges... ;-)

I've tested it with 4.4.2 now on my own box and it works fine.

Please check the output of phpversion(). Are you sure you don't use 4.2.2?

You can use this (or hardcode the host name):

list(,$host) = split(' ',php_uname());

This works for all OS that have no space in their name (eg "Linux", but not "Windows NT").

phpinfo() gives this information:

PHP Version 4.4.2

System Linux infong 2.4 #1 SMP Wed Jan 18 14:53:29 CET 2006 i686 unknown
Build Date Feb 6 2006 10:16:02
Configure Command '../configure' '--with-pear' '--with-mysql=/usr' '--with-zlib' '--enable-debug=no' '--enable-safe-mode=no' '--enable-discard-path=no' '--with-gd=/usr' '--with-png-dir=/usr/lib' '--enable-track-vars' '--with-db' '--with-gdbm' '--enable-force-cgi-redirect' '--with-ttf=/usr/' '--enable-ftp' '--with-mcrypt' '--enable-dbase' '--enable-memory-limit' '--enable-calendar' '--enable-wddx' '--with-jpeg-dir=/usr/src/kundenserver/jpeg-6b' '--enable-bcmath' '--enable-gd-imgstrttf' '--enable-shmop' '--enable-mhash' '--with-mhash=/usr/src/kundenserver/mhash-0.8.9/' '--with-openssl' '--enable-xslt' '--with-xslt-sablot' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--with-imap' '--with-curl' '--with-iconv=/usr/local' '--with-freetype-dir=/usr/include/freetype2' '--with-bz2' '--with-gettext' '--enable-exif' '--with-idn' '--enable-mbstring=all'
Server API CGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /usr/local/lib/php.ini
PHP API 20020918
PHP Extension 20020429
Zend Extension 20050606
Debug Build no
Zend Memory Manager enabled
Thread Safety disabled
Registered PHP Streams php, http, ftp, https, ftps, compress.bzip2, compress.zlib

Your proposed workaround gives as result the string "infong" but this hostname doesn't exist, so the error message is displayed again:

Warning: gethostbyaddr(): Address is not a valid IPv4 or IPv6 address

Maybe it's a special constellation on the shared webserver environment of 1&1?!

The code "echo php_uname("n"),"\n"; " gives as result:

Linux infong 2.4 #1 SMP Wed Jan 18 14:53:29 CET 2006 i686 unknown

I will now ask the support of my provider why the hostname is not given back...

Here are now some informations from the 1&1 support:

The hostname of our shared webspace is infong273.schlund.de but the function php_uname('n') gives not this hostname as result:

The result is (as mentioned above): Linux infong 2.4 #1 SMP Wed Jan 18 14:53:29 CET 2006 i686 unknown

So the typo3 class "htmlmail" doesn't work correct on the servers of 1&1. I think it's a problem of the 1&1 environment....

On the webserver at another webhosting provider (all-inkl.com) it works fine: it gives back the correct hostname.

Do you think it's possible to make a permanent workaround in the typo3 class?! e.g. using the domain name entered in the install script?

I will now overwrite the $host manually with our domain name, that works fine in the moment....

Thanks!

The 1&1 support says that I should use one of the following ways to get the hostname or the ip-address:

Hostname:
echo $_SERVER['HTTP_HOST'];

or the IP-address:

echo gethostbyname ($_SERVER['HTTP_HOST']);

or:

echo $_SERVER['SERVER_ADDR'];

They didn't answer the question, why the php_uname('n'); doesn't work... But the solution above works.

Maybe you can check if it's possible to change it in the core code...

Thanks for your help!!

Markus

$_SERVER['HTTP_HOST'] can only be one way as the class may be instantiated from a CLI script (ie outside of an HTTP server).

The patch tries $_SERVER['HTTP_HOST'] and then falls back to php_uname (with safe guards).

Fixed in CVS.