I can't reproduce this... 

Well, here is the direct link to the file in question.

http://www.php.net/do_download.php?mr=http%3A%2F%2Fau2.php.net%2F&df=php-4.3.0.tar.gz

That link leads to the .tar.tar file.

Yes, you are right. I am going to contact the maintainer, and point him to thig bugreport....

Great! Hope it gets fixed soon.

I bet this "bug" is because Windows browsers like to change the file-extension. (Using Phoenix 0.5 in Windows results in .tar.gz.tar (in every site I can remember)).
The server itself is serving the files ok.

[toni@extra:~]$ wget "http://www.php.net/do_download.php?mr=http%3A%2F%2Fau2.php.net%2F&df=php-4.3.0.tar.gz"
...
Connecting to www.php.net[64.246.30.37]:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://au2.php.net/distributions/php-4.3.0.tar.gz [following]
...
17:01:47 (107.88 KB/s) - `php-4.3.0.tar.gz' saved [4501159/4501159]

$ curl -I http://www.php.net/distributions/php-4.3.0.tar.gz
HTTP/1.1 200 OK
(...)
Content-Type: application/x-tar
Content-Encoding: x-gzip

$ curl -I http://au2.php.net/distributions/php-4.3.0.tar.gz
HTTP/1.1 200 OK
(...)
Content-Type: application/x-tar

That's the cause of the problem. Some browsers 'fix' the extension using the supplied Content-Type. It should be either application/x-gzip or application/octet-stream, which is always safe, or it should provide a Content-Encoding header.

As Sander pointed out, the server is not sending the proper HTTP headers. So the mirror setup should be corrected...

That problem should be fixed now. Apologies for the oversight.
We now replicate the behavior of the primary php.net site. 

$ curl -I http://www.php.net/distributions/php-4.3.0.tar.gz
HTTP/1.1 200 OK
(...)
Content-Type: application/x-tar
Content-Encoding: x-gzip

$ curl -I http://au2.php.net/distributions/php-4.3.0.tar.gz
HTTP/1.1 200 OK
(...)
Content-Type: application/x-tar
Content-Encoding: x-gzip

regards,

Steve

OK, so this is fixed...