Default content being added to 301 headers with PHP 5.3.5 / IIS7

On http://www.hesa.ac.uk, we are using a custom 404 handling script to redirect users from, for exmaple, http://www.hesa.ac.uk/press to the actual URL, which is an ugly CMS one: http://www.hesa.ac.uk/index.php?option=com_content&task=category&sectionid=1&id=1&Itemid=161

We're running fast-cgi.

A 301 header is sent, then a location header.

It works fine for 99% of our users but some of them are reporting 5 to 6 second loading times. This is, we think, due to a bit of stray content which is turning up in the redirection:

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.hesa.ac.uk/index.php?option=com_content&amp;task=category&amp;sectionid=1&amp;id=1&amp;Itemid=161">here</a></body>

This isn't output anywhere in the code that we can see. Here's the method which actually does the redirection:

    /**
 * Do the actual redirection to the win URL
 *
 */
function doRedirection() {


        //start output buffering to trap any content that is output by default by the headers
        @ob_start();

        //permanently moved header
        //header( 'HTTP/1.1 301 Moved Permanently' );

        //fast-cgi, so use this:        
        header('Status: 301 Moved Permanently', true);              

        @ob_end_clean(); // clear output buffer

        //location header
        header( "Location: ". $this->winUrl );  

        @ob_end_clean(); // clear output buffer

        die();



}

I cannot seem to find any resource which indicates how to stop this extra bit of content being output. I have tried various variations on the method above to do the redirection.

Has anyone had a similar problem? Does anyone have any ideas?

Cheers,

EDIT: we've become aware that this is expected behaviour for IIs7, but IIS6 never used to do it with the same code, and whether it's expected or not, our users are complaining and this seems to be the issue.

EDIT 2: it seems that the only workable solution is to abandon this approach and instead move to IIS7's url rewriting functionality, which entails writing a C# class which clones the functionality of the PHP class then plugging that into IIS.

EDIT 3: HOWEVER, setting a content-length: 0 header might possibly help. Not tested yet though.

Solution

Turns out the problem was actually the use of the built-in PHP function getHostByAddr() within the redirection code. Client hosts which do not have their DNS records set up properly experience a 5 to 6 second delay from getHostByAddr() (under IIS7, we never had this issues with IIS6). If you find an alternative function and swap it out, the problem disppears.