Why is the PHP ISAPI filter not passing the POST variables to the script?

It clearly DOES pass them, as you said it yourself:
>this works in IIS5 but not in IIS6. 
Please report it to Microsoft.

Thanks for responding so quickly Tony!

I think it is a bug in the PHP ISAPI filter because if I use a custom 404 ASP page then the POST variables do come through. It's only with PHP pages that it does not work.

I have confimed this issue, and it _is_ a PHP bug. When presented with an HTTP POST through an IIS 6 custom error handler, PHP receives the raw POST data into php://input, but fails to parse it into $_POST etc.

For comparison, ASP scripts do receive POST variables from IIS 6 custom error handlers, whereas PHP scripts do not. PHP also mangles $_SERVER['QUERY_STRING'] and $_GET and incorrectly reports $_SERVER['REQUEST_METHOD'] as 'GET' in this situation.

I can suggest that the likely reason for the above problems is that when presenting a custom error to a script ISAPI filter IIS6 prepends the error status code to the beginning of the URL (e.g. 404;http://www.example.com/) - this odd format is possibly causing confusion when PHP attempts to process the server variables.

It's hard for PHP to mangle those variables since it sets them to whatever IIS says them to be. So obviously you can't POST to custom 404 anymore. You should use $_REQUEST to refer to variables passed in such cases where you can't be sure where they come from. ;)

IIS bugs are not PHP bugs -> bogus.

I have encountered this issue working with a LAMP server running PHP. No presence 
of Microsoft's IIS.

Custom 404 pages do not seem to receive POST variables. In any URL encoded 
variables present do not get declared and $_SERVER["QUERY_STRING"] is empty. The 
query string however can be determined by looking at $_SERVER["REQUEST_URI"] 
which does come through. It seems that PHP is receiving the information but for 
some reason unknown to me, failing to parse it.

Has anyone been able to figure out how to resolve this?

I can think of many reasons why being able to post to a custom 404 is useful in 
ways that would not be handled by what is posted here.

For example if I am running a scholarship website and there is a submission 
deadline, I want to be able to catch data coming from the 404 form to recover 
the submissions and know who tried to submit which application, essay, or 
contact form but got an error that was not their fault instead. Not everyone who 
hits an error actually reports it. Some just get frustrated and leave. I can 
think of one case where a change in Godaddy's server caused such a problem. I 
was able to recover the applications because the webapp being used at the time 
dumped the information into files that it created on the server when it couldn't 
complete the request due to a broken link.