Hello! On Mon, Feb 26, 2024 at 11:13:55AM +0330, Reza Mahdi wrote:
> In the nginx project, some sort of features where rejected with certain > reasons. > For example FastCGI multiplexsion, or HTTP/2 reverse proxy both where rejected > with this reason that their backends are in the same machine as the server. > > The reason IMO is NOT acceptable in all situations. I wonder if this type of > policies will be continued in freenginx as well? Overall, I wouldn't expect major changes in the policy here. Except might be I would expect freenginx being more open and public in decisions and discussions, something I always tried to advocate for when I was an nginx developer. Still, I don't think you understand the existing policy well enough. The general policy is as follows: it's developers who decide if a particular feature should be implemented or not. Such decisions are usually made based on developers understanding about expected use cases for nginx in general, use cases for the particular feature and potential benefits from the feature in these use cases, as well as resources required to implement and maintain the particular feature. For example, requests to implement forward proxying in nginx were traditionally rejected, because nginx is not a forward proxy, but a reverse proxy. Forward proxying is a completely different use case with quite different requirements and security concerns, and even if implementation to some working extent might be simple enough, maintenance costs are going to be high, distracting developers and blurring focus of the project. If you are not happy with a decision about the particular feature, you can always discuss it and try to convince developers that it needs to be implemented, either with arguments, such as by demonstrating use cases and resulting benefits, or by providing a good implementation. -- Maxim Dounin http://mdounin.ru/ -- nginx mailing list nginx@freenginx.org https://freenginx.org/mailman/listinfo/nginx