Apache can work with FCGI the way you describe, as a proxy, but it can also run the actual FCGI in itself in contradiction to your description.

This is the problem. I never used to downvote you for this kind of persistent half-right, answer-free, unhelpful, spaghetti-flinging, discussion-style reply because you seem well-meaning but you have taken no feedback about it over time and the more the cluebat comes out the less you seem to hear.

I downvoted some of your answers for waffling, handwaving, and being free of code content or actual instruction. For exactly the reasons stated: either you're boasting about it being easy when it's not or you're just chronically lazy and would rather see a screen full of your highly affected printed voice than an answer for the OP.

I post code here pretty often that is easy (for me) and I even post things now and then that take hours to work out or explain clearly. There are dozens of monks here that do the same in the problem domains they're good at or curious about exploring. Your participation here is as lazy as it is broken.

The process has a STDIN, STDOUT, STDERR, and the FastCGI protocol essentially works from that and nothing more.

That is wrong!

What you've described is (or at least comes closest to being) CGI.

The FastCGI protocol explicitly doesn't use STDOUT & STDERR; and whilst STDIN is open, it explicitly isn't the normal STDIN; and is in fact only an alias to something else.

And you have the gall to "cordially suggest" to flexvault.

More, pointless, meaningless, malignant and destructive garbage delivered so "politely" that it persuades other know-nothings that you're being oppressed.

sundialsvc4,

...I have had no “categorical problems” with FastCGI, in Linux, AIX, or Windows settings. It has especially not been the case that FastCGI had any problems vis-a-vis Apache 1 vs. 2.

I guess you haven't done much with any of the above. Unlike you, I only answer threads that I have experience with and have some knowledge of the subject. Apache 1 was a wonderful product! It is and was a great web-server. Apache 2 is the kitchen sink of security, product authorization, analysis, etc. etc.

My answer to the original OP, was to inform him/her about my similar experience and maybe save him/her from going through months of trying to get FastCGI to work with Apache2! If the application is complex (I'm sure 'hello world' will work!), he/she may find a better alternative desirable.

There are many things I could do with Apache1 that I cannot do with Appache2. I have had to change many scripts that ran for years with Apache1, and most of the time my changes were to reduce or eliminate functionality.

Since my experience with FastCGI and Apache2, changes may have been made to improve the compatibility between the products, but my experience at the time was to try and debug two products. I choose to eliminated one of the problems, and just like FastCGI, I use a small cgi script to talk to an in-memory compiled Perl frame-work that responds to the requests.

All of this is my experience with the subject, which I wanted to help the OP with. Sorry that it doesn't agree with your experiences.

Regards...Ed