IIS6 PHP FastCGI Display Debugging Errors on Remote/Client Computers, not Generic 500 errors.

IIS7 has a simple method of allowing specific debug errors instead of generic 500 errors on remote computers (errormode=detailed & scriptErrorSentToBrowser=true). I'm looking for a way to do the same on IIS6.

This is a win2k3 development box running IIS6. Debugging is for PHP installed as fastcgi. When PHP is installed as an isapi, error handling is left to PHP - no issue. M$'s fastcgi is intercepting php cgi errors and throwing generic 500's instead (unless I logon to the server and view the page locally - full debug info available then).

How do I get IIS6 to display debugging errors on remote/client computers just like it does locally?

I can't upgrade PHP becuase the version is matched to the live server and the live server is cPanel. I can't use isapi as a work-around because I'm using fastcgi as a freeking work-around for this problem:-

http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/Q_25599844.html

I've seen a lot of solutions for iis7 - nothing or iis6.
LVL 19
v2MediaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

v2MediaAuthor Commented:
Update: got detailed errors to show on a remote computer IF page is accessed by server IP address. If accessed by fqdn, generic 500.

This was done by enabling server-side script debugging, client-side script debugging, and send detailed asp errors messages to client for the "Web Sites" folder, not the defined websites.

I guess there's some funky parent inheritance going on here - same steps didn't work on the defined site properties.
0
v2MediaAuthor Commented:
For the sake of others who get jammed in this scenario, here's the cause and a few pointers to get debuging as usual.

In both IE and FF, generic server error messages are replaced with friendly error messages under certain circumstances. If you turn off friendly error messages in IE and FF (for FF about:config browser.xul.error_pages.enabled true), the browser will show error messages from the server. However the content-length of the response from the server has to exceed a certain size. If the content length is under a certain size, the generic error page displays or no page will display.

So to work around this silly behaviour, you have to pad the error messages that the cgi produces (php in this case) so that content-length exceeds approx 512b. This is the size of the trigger in IE, but I dont know what size it is for FF - smaller, but by how much I don't care to find out.

I used the php directives error_prepend_string and error_append_string to concatenate some html styling to the errors and a lot of whitespace chars. This padded even the shortest parse error message to over 512b and viola - debug messages in FF.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
PHP

From novice to tech pro — start learning today.