Description: ------------ This is a rather strange and complex issue, please bear with me. It appears that your use of strncasecmp() in sendHeaders() is inversed - it runs only if the PHP is NOT running on a NSAPI server. There also appears to be a bug in Firefox when mangled HTTP/1.1 requests are pipelined. The bad request is mashed up with the following good request, so you get wrong headers for some requests, and HTTP headers are visible on the page (though they do not appear in View Source). So, if you have external resources (CSS or JavaScript) which are loaded via a script using HTTP_Download on a non-NSAPI server, you run a high likelihood of seeing errors on your page. The problem appears to be due to an inversed test for NSAPI. strncasecmp() returns 0 if the strings are equal (e.g. if PHP_SAPI starts with "nsapi"), yet the test is a plain if(strncasecmp(...)). Test script: --------------- <?php // This illustrates the behavior of strncasecmp() $apis = array('nsapi', 'apache2handler', 'nsapiTest123'); foreach ($apis as $api) { $res = strncasecmp($api, 'nsapi', 5); echo "API= $api " . $res . "\n"; if ($res) { echo " Test passed\n"; } } ?> Expected result: ---------------- The test for `PHP_SAPI' containing `NSAPI' should fail when it’s value is `apache2handler' Actual result: -------------- The test passes.

To comment the original (NSAPI) issue: we call flush() only if it's not NSAPI, so the source is right in this case.

Without this patch, I get this barf in my output: <br /> <b>Notice</b>: ob_flush() [<a href='ref.outcontrol'>ref.outcontrol</a>]: failed to flush buffer. No buffer to flush. in <b>HTTP/Download.php</b> on line <b>996</b><br /> Thoughts?

Changing the call to "@ob_flush()" also solves this for me, but I don't know if that is the correct thing to do here.

This updated patch also solves the issue for me, and is cleaner than using @ob_flush().

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.