If i observe it with live http headers plugin for firefox it returns a 302 redirect.

So far it seems that there hasn't been released a bugfix yet.
I would be glad to be proven wrong.

One thing i noticed is that my redirect from trailing slash to non trailing slash url in iirf is not replaced with a 302 redirect, but this doesn't help in any way and it has already been pointed out by ruslany, that the replace with 302 redirect is a bug
in the fastCGI module.

If someone has any update on the matter please post it. I have to release our new site and it is due to the fifth of december...

Today we announced release of FastCGI 1.5 for IIS5.1/6.0. The next step is now to work on back port of this for IIS7.0 which will be happening soon and should fix this defect. Stay tuned, it should be relatively fast now.

I'm pretty sure it worked a year ago when I migrated to IIS7, but I just happened to check headers were fine as I'm changing some urls and found the 302 bug. Is it know when this broke or am I imagining it ever working?

Just like to say this has solved my headache this morning, I'm glad I wasn't one of the unlucky few who have been waiting since last year. I was able to find this solution the same morning I discovered the problem.

I'm having a similar problem, but with an asp redirect instead of a php redirect. I've set up a redirect and explicitly set the response status to 301, but IIS sends a 302 status instead. Will this fix address the problem?

I am hosting my sites on a virtual server with Plesk. As soon as I updated the server it crashed and it took few hours for the engineers to revert back. I came to learn you shouldn't be updating windows directly when you have Plesk control panel installed.
All though this is not a Windows issue, I thought it's worth people know about this complication.

I think only option left for me is to control this through URL Rewrite module (which is difficult as the number of redirects are more than 6000) or Go for a fresh build server.