Feature request: FastCGI Loopback Option for Windows

[TezzerFX]

Jetty version 9.4.28.v20200408

Java version java version "1.8.0_231"

OS type/version Windows 10 Pro 1909

Description The jetty documentation presumes the use of php-fpm, this is not available in the windows PHP distribution, only instances of the php-cgi.exe can be used. A single php-cgi.exe instance doesn’t facilitate a php loopback. In order to accomplish this, I did the following:

1. Create a new BalancerFastCGIProxyServlet which was a copy of the “FastCGIProxyServlet”, in the same package.

2. Add a new InitParameter “AlternateProxyTo” for an alternate proxyTo URL, for the xml configuration.

3. Modify the new BalancerFastCGIProxyServlet to input the new InitParameter, and modify the method “sendProxyRequest” just after the proxyRequest attributes were set, to change via reflection the proxyRequest object’s uri and related data to that for the AlternateProxyTo every second request. This was done via a new “resetRequest” method which also keeps track of the proxy round robin.

This successfully accomplishes the round robin between two php-cgi.exe instances for a php loopback, but hardly seems the best way to do this going forward.

The feature request is: That it would be nice if an array of AlternateProxyTo urls could be formally an option that would round robin and load balance the FastCGI requests.

[sbordet]

A single php-cgi.exe instance doesn’t facilitate a php loopback.

Excuse my ignorance about Windows, but what does this mean exactly?

I feel you are asking to implement php-fpm for Windows, which is really not our business.

Making FastCGIProxyServlet also a load balancer and a process manager seems a bit too much.

[TezzerFX]

First this request does not ask for “process management”. Any php-cgi.exe instances would be initiated by the user. On platforms other than windows Jetty relies on FPM this does not exist for windows PHP. That means that the “ProxyTo” url can only be a single instance of a php-cgi.exe.

The proxy requests are asynchronous but each request blocks until there is a response. Which means that if a given php request initiates a loopback php request via a curl client, this then becomes a second proxy request for jetty which waits for the first request to respond, before it can make the second proxy request. The first is waiting for the curl client php response which never comes because the proxy connection is blocked and then this first request eventually gets a timeout. The second request now succeeds, but the response target no longer exists because of the first requests timeout. And... That is what is meant by “A single php-cgi.exe instance doesn’t facilitate a php loopback”.

Second all I was asking for was an option to create an array of “ProxyTo” alternate urls to enable multiple instances of the php-cgi.exe, which would be initiated by the user independent of jetty, and for a round robin access. The “proxyRequest” is an “HttpRequest” the significant URI, scheme, path and query fields are set on a per Request basis, the host and port fields are final. If an array of “AlternateProxyTo” urls (scheme, host and port) were provided each would need to be set on a round robin per request basis.

Last, I have already achieved this in a version of the FastCGIProxyServlet, namely my “BalancerFastCGIProxyServlet” in a relatively few lines of additional code, with the use of reflection to modify the HttpRequest field values corresponding to a given AlternateProxyTo url. This change consisted of a couple of extra management fields and less than 80 lines of code.

So, how hard could it be, to do this at the point where the “proxyRequest” object is generated?

The use of reflection to change private/private final fields doesn’t seem orthodox to me, and does the host and port fields in the HttpRequest have to be final?

If you cannot accommodate this, I’ll be forced to use my workaround until it breaks in some new version of jetty, otherwise “php loopbacks” via jetty on widows are impossible and it should be possible on any platform...

[sbordet]

does the host and port fields in the HttpRequest have to be final?

They are not anymore since #4787.

[TezzerFX]

Additional Proxy XML Parameters.pdf

AbstractProxyServlet.zip There are 2 attachments a pdf which shows an extract from the xml that specifies the use of the FastCGIProxyServlet, showing the extra initialization parameters needed for additional proxy URLs of the extra php.cgi.exe instances and a modified version of the AbstractProxyServlet.java file.

The changes to the “AbstractProxyServlet” are all to the “static class TransparentDelegate” and consist of 2 new fields and 27 lines of additional code: 2 method calls and 2 new methods. Each change has a comment "// Addional Code" above the line of code.

This change in conjunction with the extra initialization parameters accomplishes the round robin of the “ProxyTo” URL together with the additional proxy URLs.

The new initialization parameters are completely optional, and if omitted the functionality is that prior to any changes.

This exercise may well not meet Webtide standards, but it does completely satisfy this Feature request, with minimal coding effort and no disruption to current functionality as far as I can tell...

[stale[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to it having no activity.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to it having no activity.