1. Proposed title of this feature request
FastCGI support with OpenSHift Haproxy

2. What is the nature and description of the request?
HAProxy 2.1 introduced the ability to proxy requests directly to a FastCGI application, eliminating the need to pass the request to a webserver to do the same thing. This means that HAProxy can route requests directly to applications written in dynamic scripting languages like PHP and Python without an intermediary webserver to translate the protocol.
However, HAproxy shipped in Openshift doesn't support FastCGI, so the customer cannot use FastCGI.

3. Why does the customer need this? (List the business requirements here)
An alternative solution to the above is to install language parsing modules, such as mod_php, into the web server itself. This gives the webserver the ability to execute scripts on its own. However, that limits your ability to scale the number of processes running the script independently from the webserver. In many cases, it also means that the PHP module is loaded even for HTTP requests that don’t require PHP processing.

The better alternative is to run the script in its own process and leave the task of receiving HTTP requests to the webserver. FastCGI allows you to separate the webserver (or proxy) and the running script by defining the communication protocol between the two. Performance benchmarks indicate that separating scripts into their own process equates to a boost in performance.

4. List any affected packages or components.
Openshift HAproxy

5. Has the customer tried this before and/or outside of support and if yes, how? (Optional) //Please add any information on how you have done that so far or any ideas you'd like to share with us

This could be done by creating a custom HAProxy deployment and scaling down Ingress Operator to 0 replicas. However, as this solution would require a Support Exception, the customer has not done it. And the customer would like to include FastCGI in the Openshift HAProxy roadmap.