From mdounin at mdounin.ru  Wed Feb 14 17:59:10 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2024 20:59:10 +0300
Subject: announcing freenginx.org
Message-ID: <Zcz_bsVdky49hi0O@mdounin.ru>

Hello!

As you probably know, F5 closed Moscow office in 2022, and I no
longer work for F5 since then.  Still, we?ve reached an agreement
that I will maintain my role in nginx development as a volunteer.
And for almost two years I was working on improving nginx and
making it better for everyone, for free.

Unfortunately, some new non-technical management at F5 recently
decided that they know better how to run open source projects.  In
particular, they decided to interfere with security policy nginx
uses for years, ignoring both the policy and developers? position.

That?s quite understandable: they own the project, and can do
anything with it, including doing marketing-motivated actions,
ignoring developers position and community.  Still, this
contradicts our agreement.  And, more importantly, I no longer able
to control which changes are made in nginx within F5, and no longer
see nginx as a free and open source project developed and
maintained for the public good.

As such, starting from today, I will no longer participate in nginx
development as run by F5.  Instead, I?m starting an alternative
project, which is going to be run by developers, and not corporate
entities:

http://freenginx.org/

The goal is to keep nginx development free from arbitrary corporate
actions.  Help and contributions are welcome.  Hope it will be
beneficial for everyone.


-- 
Maxim Dounin
http://freenginx.org/


From me at gend.moe  Wed Feb 14 18:46:42 2024
From: me at gend.moe (Gentry Deng)
Date: Thu, 15 Feb 2024 02:46:42 +0800
Subject: announcing freenginx.org
In-Reply-To: <Zcz_bsVdky49hi0O@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
Message-ID: <92d0041f-6baa-450c-a63b-da0bce31461c@gend.moe>

This is shocking news, good luck to everyone.



From me at gend.moe  Wed Feb 14 19:08:50 2024
From: me at gend.moe (Gentry Deng)
Date: Thu, 15 Feb 2024 03:08:50 +0800
Subject: announcing freenginx.org
In-Reply-To: <Zcz_bsVdky49hi0O@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
Message-ID: <998ec6d2-615f-4e16-b423-85a13014d525@gend.moe>

It occurs to me that F5 may be launching a domain dispute over 
freenginx.org since they own the nginx trademark.


Example (in Chinese): https://u.sb/nginx-io/



From mdounin at mdounin.ru  Wed Feb 14 19:33:17 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2024 22:33:17 +0300
Subject: announcing freenginx.org
In-Reply-To: <998ec6d2-615f-4e16-b423-85a13014d525@gend.moe>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <998ec6d2-615f-4e16-b423-85a13014d525@gend.moe>
Message-ID: <Zc0VfY_JOfyC0TLt@mdounin.ru>

Hello!

On Thu, Feb 15, 2024 at 03:08:50AM +0800, Gentry Deng via nginx wrote:

> It occurs to me that F5 may be launching a domain dispute over freenginx.org
> since they own the nginx trademark.
> 
> 
> Example (in Chinese): https://u.sb/nginx-io/

Well, IANAL, but I tend to think they have little to no 
perspective here.  Either way, will see.

-- 
Maxim Dounin
http://mdounin.ru/


From jose.r.r at metztli.com  Wed Feb 14 18:54:11 2024
From: jose.r.r at metztli.com (jose.r.r at metztli.com)
Date: Wed, 14 Feb 2024 10:54:11 -0800
Subject: Subscribe
Message-ID: <69a33787b9cc6e2263bb268638e774b9@metztli.com>




From jfs.world at gmail.com  Wed Feb 14 19:24:59 2024
From: jfs.world at gmail.com (Jeffrey 'jf' Lim)
Date: Thu, 15 Feb 2024 03:24:59 +0800
Subject: announcing freenginx.org
In-Reply-To: <Zcz_bsVdky49hi0O@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
Message-ID: <CAE4WMGgu2vow6fjfAO8Cx_iUdoC=QQCWPCwaSLuwG6X_g77auA@mail.gmail.com>

On Thu, Feb 15, 2024 at 1:59?AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> As you probably know, F5 closed Moscow office in 2022, and I no
> longer work for F5 since then.  Still, we?ve reached an agreement
> that I will maintain my role in nginx development as a volunteer.
> And for almost two years I was working on improving nginx and
> making it better for everyone, for free.
>

wow, I did not know that. Thank you for your work and contribution over
these 2 years!



> Unfortunately, some new non-technical management at F5 recently
> decided that they know better how to run open source projects.  In
> particular, they decided to interfere with security policy nginx
> uses for years, ignoring both the policy and developers? position.
>
> That?s quite understandable: they own the project, and can do
> anything with it, including doing marketing-motivated actions,
> ignoring developers position and community.


would you be able to (within reason) give any examples of these?


  Still, this
> contradicts our agreement.  And, more importantly, I no longer able
> to control which changes are made in nginx within F5, and no longer
> see nginx as a free and open source project developed and
> maintained for the public good.
>
> As such, starting from today, I will no longer participate in nginx
> development as run by F5.  Instead, I?m starting an alternative
> project, which is going to be run by developers, and not corporate
> entities:
>
> http://freenginx.org/
>
> The goal is to keep nginx development free from arbitrary corporate
> actions.  Help and contributions are welcome.  Hope it will be
> beneficial for everyone.
>
>
thank you for continuing on with your efforts, and for this new effort!

-jf

--
He who settles on the idea of the intelligent man as a static entity only
shows himself to be a fool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240215/b646949b/attachment.htm>

From agill at hayachi.com  Wed Feb 14 19:32:48 2024
From: agill at hayachi.com (agill at hayachi.com)
Date: Wed, 14 Feb 2024 19:32:48 +0000
Subject: announcing freenginx.org
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <CAE4WMGgu2vow6fjfAO8Cx_iUdoC=QQCWPCwaSLuwG6X_g77auA@mail.gmail.com>
Message-ID: <256a9e2eae31943300e2d5be11b00b4d@hayachi.com>

Is there a way for us to also financially support the project or is it going under the umbrella of a funder?Warm regards,Amritpal GillE agill at hayachi.com | T +44 (0)2039 257 909 | M +44 (0)7540 805 359 | W https://hayachi.com | Hayachi Services<div>
</div><div>
</div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Jeffrey 'jf' Lim <jfs.world at gmail.com> </div><div>Date: 14/02/2024  19:25  (GMT+00:00) </div><div>To: nginx at nginx.org </div><div>Cc: nginx at freenginx.org, nginx-announce at freenginx.org </div><div>Subject: Re: announcing freenginx.org </div><div>
</div>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240214/1dcc8ec1/attachment.htm>

From mdounin at mdounin.ru  Wed Feb 14 19:53:08 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2024 22:53:08 +0300
Subject: announcing freenginx.org
In-Reply-To: <CAE4WMGgu2vow6fjfAO8Cx_iUdoC=QQCWPCwaSLuwG6X_g77auA@mail.gmail.com>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <CAE4WMGgu2vow6fjfAO8Cx_iUdoC=QQCWPCwaSLuwG6X_g77auA@mail.gmail.com>
Message-ID: <Zc0aJCaFBSeTDfaP@mdounin.ru>

Hello!

On Thu, Feb 15, 2024 at 03:24:59AM +0800, Jeffrey 'jf' Lim wrote:

> On Thu, Feb 15, 2024 at 1:59?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> >
> > As you probably know, F5 closed Moscow office in 2022, and I no
> > longer work for F5 since then.  Still, we?ve reached an agreement
> > that I will maintain my role in nginx development as a volunteer.
> > And for almost two years I was working on improving nginx and
> > making it better for everyone, for free.
> 
> wow, I did not know that. Thank you for your work and contribution over
> these 2 years!
> 
> > Unfortunately, some new non-technical management at F5 recently
> > decided that they know better how to run open source projects.  In
> > particular, they decided to interfere with security policy nginx
> > uses for years, ignoring both the policy and developers? position.
> >
> > That?s quite understandable: they own the project, and can do
> > anything with it, including doing marketing-motivated actions,
> > ignoring developers position and community.
> 
> would you be able to (within reason) give any examples of these?

The most recent "security advisory" was released despite the fact 
that the particular bug in the experimental HTTP/3 code is 
expected to be fixed as a normal bug as per the existing security 
policy, and all the developers, including me, agree on this.

And, while the particular action isn't exactly very bad, the 
approach in general is quite problematic.

> > Still, this
> > contradicts our agreement.  And, more importantly, I no longer able
> > to control which changes are made in nginx within F5, and no longer
> > see nginx as a free and open source project developed and
> > maintained for the public good.
> >
> > As such, starting from today, I will no longer participate in nginx
> > development as run by F5.  Instead, I?m starting an alternative
> > project, which is going to be run by developers, and not corporate
> > entities:
> >
> > http://freenginx.org/
> >
> > The goal is to keep nginx development free from arbitrary corporate
> > actions.  Help and contributions are welcome.  Hope it will be
> > beneficial for everyone.
> >
> >
> thank you for continuing on with your efforts, and for this new effort!

Thanks, appreciated.

-- 
Maxim Dounin
http://mdounin.ru/


From mdounin at mdounin.ru  Wed Feb 14 20:00:14 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2024 23:00:14 +0300
Subject: announcing freenginx.org
In-Reply-To: <256a9e2eae31943300e2d5be11b00b4d@hayachi.com>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <CAE4WMGgu2vow6fjfAO8Cx_iUdoC=QQCWPCwaSLuwG6X_g77auA@mail.gmail.com>
 <256a9e2eae31943300e2d5be11b00b4d@hayachi.com>
Message-ID: <Zc0bzqfYeTl295lr@mdounin.ru>

Hello!

On Wed, Feb 14, 2024 at 07:32:48PM +0000, agill--- via nginx wrote:

> Is there a way for us to also financially support the project or 
> is it going under the umbrella of a funder?

Thanks for the suggestion.  For now, I have enough resources to 
support the project and myself.

-- 
Maxim Dounin
http://mdounin.ru/


From noloader at gmail.com  Wed Feb 14 20:56:01 2024
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 14 Feb 2024 15:56:01 -0500
Subject: announcing freenginx.org
In-Reply-To: <Zcz_bsVdky49hi0O@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
Message-ID: <CAH8yC8=+fMPzgB4HqP9_w1KtJ+Tskni6BRs5CFumSddqKdH7tw@mail.gmail.com>

On Wed, Feb 14, 2024 at 12:59?PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> As you probably know, F5 closed Moscow office in 2022, and I no
> longer work for F5 since then.  Still, we?ve reached an agreement
> that I will maintain my role in nginx development as a volunteer.
> And for almost two years I was working on improving nginx and
> making it better for everyone, for free.
>
> Unfortunately, some new non-technical management at F5 recently
> decided that they know better how to run open source projects.  In
> particular, they decided to interfere with security policy nginx
> uses for years, ignoring both the policy and developers? position.
>
> That?s quite understandable: they own the project, and can do
> anything with it, including doing marketing-motivated actions,
> ignoring developers position and community.  Still, this
> contradicts our agreement.  And, more importantly, I no longer able
> to control which changes are made in nginx within F5, and no longer
> see nginx as a free and open source project developed and
> maintained for the public good.
>
> As such, starting from today, I will no longer participate in nginx
> development as run by F5.  Instead, I?m starting an alternative
> project, which is going to be run by developers, and not corporate
> entities:
>
> http://freenginx.org/
>
> The goal is to keep nginx development free from arbitrary corporate
> actions.  Help and contributions are welcome.  Hope it will be
> beneficial for everyone.

Thanks for all the hard work, Maxim.

There's a Request for Packaging for freenginx over at Debian at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063916>. Hopefully
someone will pick it up quickly.

Jeff


From al-freenginx at none.at  Wed Feb 14 21:18:33 2024
From: al-freenginx at none.at (Aleksandar Lazic)
Date: Wed, 14 Feb 2024 22:18:33 +0100
Subject: announcing freenginx.org
In-Reply-To: <Zcz_bsVdky49hi0O@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
Message-ID: <8cc78590-1ea9-498c-8ff7-4c5d72348c58@none.at>

Hi Maxim.

On 2024-02-14 (Mi.) 18:59, Maxim Dounin wrote:
> Hello!
> 
> As you probably know, F5 closed Moscow office in 2022, and I no
> longer work for F5 since then.  Still, we?ve reached an agreement
> that I will maintain my role in nginx development as a volunteer.
> And for almost two years I was working on improving nginx and
> making it better for everyone, for free.

Thank you and respect.

> Unfortunately, some new non-technical management at F5 recently
> decided that they know better how to run open source projects.  In
> particular, they decided to interfere with security policy nginx
> uses for years, ignoring both the policy and developers? position.
> 
> That?s quite understandable: they own the project, and can do
> anything with it, including doing marketing-motivated actions,
> ignoring developers position and community.  Still, this
> contradicts our agreement.  And, more importantly, I no longer able
> to control which changes are made in nginx within F5, and no longer
> see nginx as a free and open source project developed and
> maintained for the public good.

Oh that's really sad :-(

> As such, starting from today, I will no longer participate in nginx
> development as run by F5.  Instead, I?m starting an alternative
> project, which is going to be run by developers, and not corporate
> entities:
> 
> http://freenginx.org/
> 
> The goal is to keep nginx development free from arbitrary corporate
> actions.  Help and contributions are welcome.  Hope it will be
> beneficial for everyone.

Do you know if Igor plans to join freenginx?

Best Regards
Alex


From mdounin at mdounin.ru  Wed Feb 14 21:43:52 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 15 Feb 2024 00:43:52 +0300
Subject: announcing freenginx.org
In-Reply-To: <8cc78590-1ea9-498c-8ff7-4c5d72348c58@none.at>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <8cc78590-1ea9-498c-8ff7-4c5d72348c58@none.at>
Message-ID: <Zc00GDdRYluN3pXq@mdounin.ru>

Hello!

On Wed, Feb 14, 2024 at 10:18:33PM +0100, Aleksandar Lazic via nginx wrote:

> Hi Maxim.
> 
> On 2024-02-14 (Mi.) 18:59, Maxim Dounin wrote:
> > Hello!
> > 
> > As you probably know, F5 closed Moscow office in 2022, and I no
> > longer work for F5 since then.  Still, we?ve reached an agreement
> > that I will maintain my role in nginx development as a volunteer.
> > And for almost two years I was working on improving nginx and
> > making it better for everyone, for free.
> 
> Thank you and respect.

Thanks.

> > Unfortunately, some new non-technical management at F5 recently
> > decided that they know better how to run open source projects.  In
> > particular, they decided to interfere with security policy nginx
> > uses for years, ignoring both the policy and developers? position.
> > 
> > That?s quite understandable: they own the project, and can do
> > anything with it, including doing marketing-motivated actions,
> > ignoring developers position and community.  Still, this
> > contradicts our agreement.  And, more importantly, I no longer able
> > to control which changes are made in nginx within F5, and no longer
> > see nginx as a free and open source project developed and
> > maintained for the public good.
> 
> Oh that's really sad :-(
> 
> > As such, starting from today, I will no longer participate in nginx
> > development as run by F5.  Instead, I?m starting an alternative
> > project, which is going to be run by developers, and not corporate
> > entities:
> > 
> > http://freenginx.org/
> > 
> > The goal is to keep nginx development free from arbitrary corporate
> > actions.  Help and contributions are welcome.  Hope it will be
> > beneficial for everyone.
> 
> Do you know if Igor plans to join freenginx?

He has no such plans (just asked).  Though he wasn't active in 
nginx development for many years now, so that's not a surprise.

-- 
Maxim Dounin
http://mdounin.ru/


From manuel.baesler at gmail.com  Thu Feb 15 01:33:51 2024
From: manuel.baesler at gmail.com (Manuel)
Date: Thu, 15 Feb 2024 02:33:51 +0100
Subject: announcing freenginx.org
In-Reply-To: <Zcz_bsVdky49hi0O@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
Message-ID: <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>

Good Evening Maxim,

thank you for the work.

I am speechless. My personal opinion:
@F5 get an advisor for open source
and maybe read something about enshittification m(

TT

Will follow freenginx then.
Thx.


> Am 14.02.2024 um 18:59 schrieb Maxim Dounin <mdounin at mdounin.ru>:
> 
> ?Hello!
> 
> As you probably know, F5 closed Moscow office in 2022, and I no
> longer work for F5 since then.  Still, we?ve reached an agreement
> that I will maintain my role in nginx development as a volunteer.
> And for almost two years I was working on improving nginx and
> making it better for everyone, for free.
> 
> Unfortunately, some new non-technical management at F5 recently
> decided that they know better how to run open source projects.  In
> particular, they decided to interfere with security policy nginx
> uses for years, ignoring both the policy and developers? position.
> 
> That?s quite understandable: they own the project, and can do
> anything with it, including doing marketing-motivated actions,
> ignoring developers position and community.  Still, this
> contradicts our agreement.  And, more importantly, I no longer able
> to control which changes are made in nginx within F5, and no longer
> see nginx as a free and open source project developed and
> maintained for the public good.
> 
> As such, starting from today, I will no longer participate in nginx
> development as run by F5.  Instead, I?m starting an alternative
> project, which is going to be run by developers, and not corporate
> entities:
> 
> http://freenginx.org/
> 
> The goal is to keep nginx development free from arbitrary corporate
> actions.  Help and contributions are welcome.  Hope it will be
> beneficial for everyone.
> 
> 
> --
> Maxim Dounin
> http://freenginx.org/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx


From mdounin at mdounin.ru  Thu Feb 15 10:24:13 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 15 Feb 2024 13:24:13 +0300
Subject: announcing freenginx.org
In-Reply-To: <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
Message-ID: <Zc3mTY0I8GJxyoWC@mdounin.ru>

Hello!

On Thu, Feb 15, 2024 at 02:33:51AM +0100, Manuel wrote:

> Good Evening Maxim,
> 
> thank you for the work.
> 
> I am speechless. My personal opinion:
> @F5 get an advisor for open source
> and maybe read something about enshittification m(
> 
> TT
> 
> Will follow freenginx then.
> Thx.

Thanks.

Interesting term, never heard it before.

-- 
Maxim Dounin
http://mdounin.ru/


From Sam at SimpleSamples.info  Thu Feb 15 15:53:55 2024
From: Sam at SimpleSamples.info (Sam Hobbs)
Date: Thu, 15 Feb 2024 07:53:55 -0800
Subject: announcing freenginx.org
In-Reply-To: <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
Message-ID: <be268be7-e730-9bed-64ce-e7713aeaa3c0@SimpleSamples.info>

Enshittification is not a generally accepted term. It was created. There are probably simpler ways to say what is meant, such as degrade and shift.



Manuel wrote on 2/14/2024 5:33 PM:
> @F5 get an advisor for open source
> and maybe read something about enshittification m(
>



From stef at boinon.xyz  Thu Feb 15 16:15:35 2024
From: stef at boinon.xyz (stef)
Date: Thu, 15 Feb 2024 17:15:35 +0100
Subject: announcing freenginx.org
In-Reply-To: <be268be7-e730-9bed-64ce-e7713aeaa3c0@SimpleSamples.info>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
 <be268be7-e730-9bed-64ce-e7713aeaa3c0@SimpleSamples.info>
Message-ID: <9f2be011-3378-48b7-8993-e5e218b089ab@boinon.xyz>

How does it work in practice? I have a Debian server using nginx, how do 
I switch to freenginx?
F**k enshittification. It's the same thing every time business gets its 
grubby mitts on free software.


From mdounin at mdounin.ru  Thu Feb 15 16:34:46 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 15 Feb 2024 19:34:46 +0300
Subject: announcing freenginx.org
In-Reply-To: <9f2be011-3378-48b7-8993-e5e218b089ab@boinon.xyz>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
 <be268be7-e730-9bed-64ce-e7713aeaa3c0@SimpleSamples.info>
 <9f2be011-3378-48b7-8993-e5e218b089ab@boinon.xyz>
Message-ID: <Zc49JkYoXzWTS_Ek@mdounin.ru>

Hello!

On Thu, Feb 15, 2024 at 05:15:35PM +0100, stef wrote:

> How does it work in practice? I have a Debian server using nginx, how do I
> switch to freenginx?
> F**k enshittification. It's the same thing every time business gets its
> grubby mitts on free software.

For now, the freenginx project is just created.  A first release 
is expected shortly, then you'll be able to switch.

-- 
Maxim Dounin
http://mdounin.ru/


From warlock at x-y.one  Thu Feb 15 18:09:11 2024
From: warlock at x-y.one (warlock at x-y.one)
Date: Thu, 15 Feb 2024 15:09:11 -0300
Subject: announcing freenginx.org
In-Reply-To: <Zc49JkYoXzWTS_Ek@mdounin.ru>
References: <Zcz_bsVdky49hi0O@mdounin.ru>
 <3D71D289-EA4E-44FC-BE10-35C4DBC50F71@gmail.com>
 <be268be7-e730-9bed-64ce-e7713aeaa3c0@SimpleSamples.info>
 <9f2be011-3378-48b7-8993-e5e218b089ab@boinon.xyz>
 <Zc49JkYoXzWTS_Ek@mdounin.ru>
Message-ID: <6b38ee65888ec8e0c62fa542f3528a27@x-y.one>

On 2024-02-15 13:34, Maxim Dounin wrote:
> Hello!
> 
> On Thu, Feb 15, 2024 at 05:15:35PM +0100, stef wrote:
> 
>> How does it work in practice? I have a Debian server using nginx, how 
>> do I
>> switch to freenginx?
>> F**k enshittification. It's the same thing every time business gets 
>> its
>> grubby mitts on free software.
> 
> For now, the freenginx project is just created.  A first release
> is expected shortly, then you'll be able to switch.
> 
> --
> Maxim Dounin
> http://mdounin.ru/
I'd like to help the project in any way needed.


From jeffsilverm at gmail.com  Sun Feb 18 04:56:03 2024
From: jeffsilverm at gmail.com (Jeff Silverman)
Date: Sat, 17 Feb 2024 20:56:03 -0800
Subject: F5 taking over nginx
Message-ID: <f00cac2c-1410-453f-b793-8daf369042ed@gmail.com>

People,


I used to work for F5 networks.? In fact, shortly after F5 bought nginx, 
I applied for a customer support position to support nginx (I wasn't 
hired).? I would be willing to walk down there (I live almost but not 
quite within walking distance of their corporate HQ so I would actually 
take a bus) and talk to them, to see if I could be the open source 
coordinator for them.? They will probably say "no" but we won't know 
until I ask.

Does anybody on this list have an opinion about take over?? I would like 
to have some sort of "official" consensus before I do that.? Perhaps if 
people want to give me some bullet points.

* What happened to MySQL when Sun bought them, and then Oracle bought 
Sun?? How does mariadb compare with MySQL?? There is one article 
(https://www.hostinger.com/tutorials/mariadb-vs-mysql) which says the 
answer is "mixed".

*? I am going to teach a class in nginx starting soon (I can't go into 
details because I signed an NDA).? One of the slides is very careful to 
distinguish between nginx.org and nginx.com.? Now that nginx.org is 
freenginx.org, that will actually make that slide simpler which is A 
Good Thing, for very small values of "Good".

* Your bullet point here.

In terms of the trademark issue, Redhat had a series of meetings with 
the people at CENTOS, at which time they hammered out what belonged to 
Redhat and what belonged to the world through the GPL.? IANAL, but my 
experience with various law suits is that one of the first questions the 
judge is going to ask is "Did you attempt to negotiate a settlement 
before hand?"? If the answer is no, then the judge will order some sort 
of negotiation or arbitration.? Court room time is precious, and it is 
cheaper to negotiate than to litigate.? Frequently, negotiation yields a 
"fair" solution.


Please give this offer a bit of thought.

Thank you


Jeff





From pgnd at dev-mail.net  Sun Feb 18 14:01:58 2024
From: pgnd at dev-mail.net (pgnd)
Date: Sun, 18 Feb 2024 09:01:58 -0500
Subject: F5 taking over nginx
In-Reply-To: <f00cac2c-1410-453f-b793-8daf369042ed@gmail.com>
References: <f00cac2c-1410-453f-b793-8daf369042ed@gmail.com>
Message-ID: <ed6bcd6f-4a01-4591-95ca-a1d89024ff32@dev-mail.net>

> Now that nginx.org is freenginx.org

??

freenginx.org is the site for Maxim's fork.

nginx.org is the site for F5's Nginx community release.

can you point to what/where indicates that isn't the case?
afaik, Nginx.org & the F5 'community' nginx release is still alive & well



From me at gend.moe  Sun Feb 18 14:32:52 2024
From: me at gend.moe (Gentry Deng)
Date: Sun, 18 Feb 2024 22:32:52 +0800
Subject: F5 taking over nginx
In-Reply-To: <f00cac2c-1410-453f-b793-8daf369042ed@gmail.com>
References: <f00cac2c-1410-453f-b793-8daf369042ed@gmail.com>
Message-ID: <f907873e-aab1-48fb-89fc-ba3f2466db35@gend.moe>

Arbitration on domain names is not court related, it is provided by WIPO 
<https://www.wipo.int/>.

As far as I know, nginx.io (now is n.wtf <https://n.wtf/>), which 
provides a third-party Debian nginx source, has been ruled to be using 
the trademark in bad faith.

I'm sure freenginx.org will suffer the same fate.

Judgement on nginx.io: 
https://www.wipo.int/amc/en/domains/decisions/pdf/2022/dio2022-0006.pdf


On 2024/2/18 12:56 UTC+08:00, Jeff Silverman wrote:
> In terms of the trademark issue, Redhat had a series of meetings with 
> the people at CENTOS, at which time they hammered out what belonged to 
> Redhat and what belonged to the world through the GPL.? IANAL, but my 
> experience with various law suits is that one of the first questions 
> the judge is going to ask is "Did you attempt to negotiate a 
> settlement before hand?"? If the answer is no, then the judge will 
> order some sort of negotiation or arbitration.? Court room time is 
> precious, and it is cheaper to negotiate than to litigate.? 
> Frequently, negotiation yields a "fair" solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240218/ffa8ed8b/attachment.htm>

From admin at rzmahdi.ir  Sun Feb 18 17:38:04 2024
From: admin at rzmahdi.ir (Reza Mahdi)
Date: Sun, 18 Feb 2024 21:08:04 +0330
Subject: Suggest to rename project
Message-ID: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>

Hello, all

As others say, F5 can do many things, unfortunately. I think the main
force lever of corporation is the name. Personally love the word nginx
but ant derivative about it can make trouble specially for Mr. Dounin.

I suggest to change the name. By the way it's Mr. Dounin's project.

---
Best regards
Reza Mahdi


From trashcan at ellael.org  Sun Feb 18 19:28:15 2024
From: trashcan at ellael.org (Michael Grimm)
Date: Sun, 18 Feb 2024 20:28:15 +0100
Subject: Suggest to rename project
In-Reply-To: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
Message-ID: <00626754-959C-44D1-93F8-CD8190678A26@ellael.org>

Reza Mahdi <admin at rzmahdi.ir> wrote:

> I suggest to change the name.

machinx

> By the way it's Mr. Dounin's project.

ACK

Michael



From mdounin at mdounin.ru  Sun Feb 18 20:24:07 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 18 Feb 2024 23:24:07 +0300
Subject: Suggest to rename project
In-Reply-To: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
Message-ID: <ZdJnZz4UJ9lt17Yo@mdounin.ru>

Hello!

On Sun, Feb 18, 2024 at 09:08:04PM +0330, Reza Mahdi wrote:

> Hello, all
> 
> As others say, F5 can do many things, unfortunately. I think the main
> force lever of corporation is the name. Personally love the word nginx
> but ant derivative about it can make trouble specially for Mr. Dounin.
> 
> I suggest to change the name. By the way it's Mr. Dounin's project.

The "freenginx" name expresses the goals of the project very well, 
and therefore I would like to preserve the name as is, even if it 
implies some risks.

IANAL, but from my understanding the name "freenginx" is 
sufficiently different from the "NGINX" trademark F5 has.  And 
there is a quite similar precedent in the past, the FreeBSD 
project and BSD trademark.

If F5 will nevertheless decide to make a legal action against the 
project, renaming the project would always be an option.

-- 
Maxim Dounin
http://mdounin.ru/


From ceau74 at gmail.com  Mon Feb 19 03:47:26 2024
From: ceau74 at gmail.com (Cesar L. C.)
Date: Sun, 18 Feb 2024 22:47:26 -0500
Subject: Suggest to rename project
In-Reply-To: <ZdJnZz4UJ9lt17Yo@mdounin.ru>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
 <ZdJnZz4UJ9lt17Yo@mdounin.ru>
Message-ID: <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>

Hello...

The name I propose is:

SuperServerX

Regards.

El dom, 18 feb 2024, 3:24 p. m., Maxim Dounin <mdounin at mdounin.ru> escribi?:

> Hello!
>
> On Sun, Feb 18, 2024 at 09:08:04PM +0330, Reza Mahdi wrote:
>
> > Hello, all
> >
> > As others say, F5 can do many things, unfortunately. I think the main
> > force lever of corporation is the name. Personally love the word nginx
> > but ant derivative about it can make trouble specially for Mr. Dounin.
> >
> > I suggest to change the name. By the way it's Mr. Dounin's project.
>
> The "freenginx" name expresses the goals of the project very well,
> and therefore I would like to preserve the name as is, even if it
> implies some risks.
>
> IANAL, but from my understanding the name "freenginx" is
> sufficiently different from the "NGINX" trademark F5 has.  And
> there is a quite similar precedent in the past, the FreeBSD
> project and BSD trademark.
>
> If F5 will nevertheless decide to make a legal action against the
> project, renaming the project would always be an option.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> --
> nginx mailing list
> nginx at freenginx.org
> https://freenginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240218/2770a3d5/attachment.htm>

From admin at rzmahdi.ir  Mon Feb 19 09:45:14 2024
From: admin at rzmahdi.ir (Reza Mahdi)
Date: Mon, 19 Feb 2024 13:15:14 +0330
Subject: Mirror GIT Repository
Message-ID: <CZ8YJH2DR9AP.2XLT6RHICNI1M@rzmahdi.ir>

Hello!

Now that project is more community-driven, I want suggest to have a GIT
mirror repository. This can have a positive effect on contributors count.

There will no need to MOVE the project to git, Just a mirror that is
updated once in a while.

--
Reza Mahdi



From mdounin at mdounin.ru  Mon Feb 19 13:25:45 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 19 Feb 2024 16:25:45 +0300
Subject: Mirror GIT Repository
In-Reply-To: <CZ8YJH2DR9AP.2XLT6RHICNI1M@rzmahdi.ir>
References: <CZ8YJH2DR9AP.2XLT6RHICNI1M@rzmahdi.ir>
Message-ID: <ZdNW2Ucc6-RL5EaB@mdounin.ru>

Hello!

On Mon, Feb 19, 2024 at 01:15:14PM +0330, Reza Mahdi wrote:

> Hello!
> 
> Now that project is more community-driven, I want suggest to have a GIT
> mirror repository. This can have a positive effect on contributors count.
> 
> There will no need to MOVE the project to git, Just a mirror that is
> updated once in a while.

Thanks for the suggestion, github mirror is planned.

-- 
Maxim Dounin
http://mdounin.ru/


From john at cibolo.com  Mon Feb 19 14:08:00 2024
From: john at cibolo.com (John Griessen)
Date: Mon, 19 Feb 2024 08:08:00 -0600
Subject: Suggest to rename project
In-Reply-To: <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
 <ZdJnZz4UJ9lt17Yo@mdounin.ru>
 <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>
Message-ID: <b368b789-af33-40c1-833b-98757220e420@cibolo.com>

On 2/18/24 20:47, Cesar L. C. wrote:
> Hello...
> 
> The name I propose is:
> 
> SuperServerX

nginy
nginz
planetngin
worldengin
globalengin
moonengin
starengin
enginstar
engin*




From showfom at gmail.com  Mon Feb 19 17:07:29 2024
From: showfom at gmail.com (Xiufeng Guo)
Date: Tue, 20 Feb 2024 02:07:29 +0900
Subject: Suggest to rename project
In-Reply-To: <b368b789-af33-40c1-833b-98757220e420@cibolo.com>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
 <ZdJnZz4UJ9lt17Yo@mdounin.ru>
 <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>
 <b368b789-af33-40c1-833b-98757220e420@cibolo.com>
Message-ID: <CADrM9izACdsBEjaZW8p841AE73iYgJvU4-3wHuYSZmhUU4a+4w@mail.gmail.com>

We've been through this before, F5 filed a UDRP complaint and tookour
domain nginx.io in 2022 and we were forced to rename our project as
n.wtf.

They wouldn't even let us use nginx.u.sb for our project.

Therefore, I propose we change the name of freenginx.

https://u.sb/nginx-io/
https://u.sb/files/Decision-DIO2022-0006.pdf

On Mon, Feb 19, 2024 at 11:08?PM John Griessen via nginx
<nginx at freenginx.org> wrote:
>
> On 2/18/24 20:47, Cesar L. C. wrote:
> > Hello...
> >
> > The name I propose is:
> >
> > SuperServerX
>
> nginy
> nginz
> planetngin
> worldengin
> globalengin
> moonengin
> starengin
> enginstar
> engin*
>
>
> --
> nginx mailing list
> nginx at freenginx.org
> https://freenginx.org/mailman/listinfo/nginx



-- 
Best Regards,
Xiufeng Guo


From brabo at cryptolab.net  Tue Feb 20 01:31:04 2024
From: brabo at cryptolab.net (brabo)
Date: Tue, 20 Feb 2024 02:31:04 +0100
Subject: Suggest to rename project
In-Reply-To: <CADrM9izACdsBEjaZW8p841AE73iYgJvU4-3wHuYSZmhUU4a+4w@mail.gmail.com>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
 <ZdJnZz4UJ9lt17Yo@mdounin.ru>
 <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>
 <b368b789-af33-40c1-833b-98757220e420@cibolo.com>
 <CADrM9izACdsBEjaZW8p841AE73iYgJvU4-3wHuYSZmhUU4a+4w@mail.gmail.com>
Message-ID: <20240220023104.5f0c7885.brabo@cryptolab.net>

On Tue, 20 Feb 2024 02:07:29 +0900
Xiufeng Guo <showfom at gmail.com> wrote:

> We've been through this before, F5 filed a UDRP complaint and tookour
> domain nginx.io in 2022 and we were forced to rename our project as
> n.wtf.
> 
> They wouldn't even let us use nginx.u.sb for our project.
> 
> Therefore, I propose we change the name of freenginx.
> 
> https://u.sb/nginx-io/
> https://u.sb/files/Decision-DIO2022-0006.pdf
> 
> On Mon, Feb 19, 2024 at 11:08?PM John Griessen via nginx
> <nginx at freenginx.org> wrote:
> >
> > On 2/18/24 20:47, Cesar L. C. wrote:  
> > > Hello...
> > >
> > > The name I propose is:
> > >
> > > SuperServerX  
> >
> > nginy
> > nginz
> > planetngin
> > worldengin
> > globalengin
> > moonengin
> > starengin
> > enginstar
> > engin*
> >
> >
> > --
> > nginx mailing list
> > nginx at freenginx.org
> > https://freenginx.org/mailman/listinfo/nginx  
> 
> 
> 

I think Maxim is entirely correct and justified.
And, if F5 would desire to venture into any legal action, the community
can very easily deploy the Streisand effect.

In such case, let us simply have many forks!

freenginx
opennginx
netnginx
tuxnginx
nixnginx

I stop here. Imaginations need space as well ;')

brabo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://freenginx.org/pipermail/nginx/attachments/20240220/5fe915cf/attachment.sig>

From ozgurkazancci at gmail.com  Tue Feb 20 14:29:53 2024
From: ozgurkazancci at gmail.com (=?UTF-8?B?w5Z6Z8O8ciBLb25zdGFudGluIEthemFuw6fDp8Sx?=)
Date: Tue, 20 Feb 2024 17:29:53 +0300
Subject: Suggest to rename project
In-Reply-To: <20240220023104.5f0c7885.brabo@cryptolab.net>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
 <ZdJnZz4UJ9lt17Yo@mdounin.ru>
 <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>
 <b368b789-af33-40c1-833b-98757220e420@cibolo.com>
 <CADrM9izACdsBEjaZW8p841AE73iYgJvU4-3wHuYSZmhUU4a+4w@mail.gmail.com>
 <20240220023104.5f0c7885.brabo@cryptolab.net>
Message-ID: <CA+GnASdEUC0Tn=HwNgZF+Ttncr+iNZR_X1--mG1u+PFRiD8N9w@mail.gmail.com>

On Tue, Feb 20, 2024 at 4:33?AM brabo via nginx <nginx at freenginx.org> wrote:

> On Tue, 20 Feb 2024 02:07:29 +0900
> Xiufeng Guo <showfom at gmail.com> wrote:
>
> > We've been through this before, F5 filed a UDRP complaint and tookour
> > domain nginx.io in 2022 and we were forced to rename our project as
> > n.wtf.
> >
> > They wouldn't even let us use nginx.u.sb for our project.
> >
> > Therefore, I propose we change the name of freenginx.
> >
> > https://u.sb/nginx-io/
> > https://u.sb/files/Decision-DIO2022-0006.pdf
> >
> > On Mon, Feb 19, 2024 at 11:08?PM John Griessen via nginx
> > <nginx at freenginx.org> wrote:
> > >
> > > On 2/18/24 20:47, Cesar L. C. wrote:
> > > > Hello...
> > > >
> > > > The name I propose is:
> > > >
> > > > SuperServerX
> > >
> > > nginy
> > > nginz
> > > planetngin
> > > worldengin
> > > globalengin
> > > moonengin
> > > starengin
> > > enginstar
> > > engin*
> > >
> > >
> > > --
> > > nginx mailing list
> > > nginx at freenginx.org
> > > https://freenginx.org/mailman/listinfo/nginx
> >
> >
> >
>
> I think Maxim is entirely correct and justified.
> And, if F5 would desire to venture into any legal action, the community
> can very easily deploy the Streisand effect.
>
> In such case, let us simply have many forks!
>
> freenginx
> opennginx
> netnginx
> tuxnginx
> nixnginx
>
> I stop here. Imaginations need space as well ;')
>
> brabo.
> --
> nginx mailing list
> nginx at freenginx.org
> https://freenginx.org/mailman/listinfo/nginx



I think we should stop trolling the mailing list with some horrible random
names,
and focus on what Xiufeng said/posted;

https://u.sb/files/Decision-DIO2022-0006.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240220/4e9067ad/attachment.htm>

From mdounin at mdounin.ru  Tue Feb 20 17:45:07 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 20 Feb 2024 20:45:07 +0300
Subject: nginx-1.25.4
Message-ID: <ZdTlI4QKiQy07A0g@mdounin.ru>

Changes with freenginx 1.25.4                                    20 Feb 2024

    *) Change: now the "freenginx" name is used in responses.

    *) Bugfix: "open socket left" alerts might appear in logs during worker
       processes shutdown when using AIO.

    *) Bugfix: a segmentation fault might occur in a worker process if AIO
       was used in subrequests.

    *) Bugfix: a segmentation fault might occur in a worker process if the
       "image_filter" directive was used, and errors with code 415 were
       redirected with the "error_page" directive.

    *) Bugfix: a segmentation fault might occur in a worker process when
       handling cached responses with the "X-Accel-Redirect" header.
       Thanks to Ji?? Setni?ka.

    *) Bugfix: a segmentation fault might occur in a worker process when
       using HTTP/3.

    *) Bugfixes and improvements in HTTP/3.


-- 
Maxim Dounin
http://freenginx.org/


From hjckr at oldum.net  Tue Feb 20 18:14:00 2024
From: hjckr at oldum.net (Nikolay Kichukov)
Date: Tue, 20 Feb 2024 20:14:00 +0200
Subject: nginx-1.25.4
In-Reply-To: <ZdTlI4QKiQy07A0g@mdounin.ru>
References: <ZdTlI4QKiQy07A0g@mdounin.ru>
Message-ID: <547bac02a09b14bf0d0ed664b5f4a98b89761e79.camel@oldum.net>

Thank you for this release, I was awaiting it so I could open a request
to have it included in portage ( the GNU/Gentoo package repository ).
Here it is now:

https://bugs.gentoo.org/925098

Cheers,
-Nikolay

On Tue, 2024-02-20 at 20:45 +0300, Maxim Dounin wrote:
> Changes with freenginx 1.25.4??????????????????????????????????? 20
> Feb 2024
> 
> ??? *) Change: now the "freenginx" name is used in responses.
> 
> ??? *) Bugfix: "open socket left" alerts might appear in logs during
> worker
> ?????? processes shutdown when using AIO.
> 
> ??? *) Bugfix: a segmentation fault might occur in a worker process if
> AIO
> ?????? was used in subrequests.
> 
> ??? *) Bugfix: a segmentation fault might occur in a worker process if
> the
> ?????? "image_filter" directive was used, and errors with code 415
> were
> ?????? redirected with the "error_page" directive.
> 
> ??? *) Bugfix: a segmentation fault might occur in a worker process
> when
> ?????? handling cached responses with the "X-Accel-Redirect" header.
> ?????? Thanks to Ji?? Setni?ka.
> 
> ??? *) Bugfix: a segmentation fault might occur in a worker process
> when
> ?????? using HTTP/3.
> 
> ??? *) Bugfixes and improvements in HTTP/3.
> 
> 
> -- 
> Maxim Dounin
> http://freenginx.org/



From Sam at SimpleSamples.info  Tue Feb 20 22:15:29 2024
From: Sam at SimpleSamples.info (Sam Hobbs)
Date: Tue, 20 Feb 2024 14:15:29 -0800
Subject: Suggest to rename project
In-Reply-To: <CA+GnASdEUC0Tn=HwNgZF+Ttncr+iNZR_X1--mG1u+PFRiD8N9w@mail.gmail.com>
References: <CZ8DYYFV5SCW.2G2XDN68FKOEC@rzmahdi.ir>
 <ZdJnZz4UJ9lt17Yo@mdounin.ru>
 <CANrSF2vB53uStiSCxoLd3ZBrfFfQXukS_jhBCubSwF0jiMfBgg@mail.gmail.com>
 <b368b789-af33-40c1-833b-98757220e420@cibolo.com>
 <CADrM9izACdsBEjaZW8p841AE73iYgJvU4-3wHuYSZmhUU4a+4w@mail.gmail.com>
 <20240220023104.5f0c7885.brabo@cryptolab.net>
 <CA+GnASdEUC0Tn=HwNgZF+Ttncr+iNZR_X1--mG1u+PFRiD8N9w@mail.gmail.com>
Message-ID: <1e073e90-182f-855a-1de1-db78f596c360@SimpleSamples.info>

A relevant dictionary definition of troll is:

> to antagonize (others) online by deliberately posting inflammatory, 
> irrelevant, or offensive comments or other disruptive content

Is that what you are saying? Some people have begun using the term troll 
for anything they do not like. Is that what you mean?

There is much in the PDF. Can someone summarize it? I think it 
essentially says that |nginx.io| must be transferred to F5.


?zg?r Konstantin Kazan??? wrote on 2/20/2024 6:29 AM:
>
> I think we should stop trolling the mailing list with some horrible 
> random names,
> and focus on what Xiufeng said/posted;
>
> https://u.sb/files/Decision-DIO2022-0006.pdf
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240220/0c27d858/attachment.htm>

From n33kproton at protonmail.com  Wed Feb 21 01:26:28 2024
From: n33kproton at protonmail.com (n33kproton)
Date: Wed, 21 Feb 2024 01:26:28 +0000
Subject: Suggest to rename project
Message-ID: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>

Maintaining the name "nginx" is importanto IMO to understand the goal of the project, but i would suggest something like "libre"
https://www.gnu.org/philosophy/free-sw.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240221/91cbefd8/attachment.htm>

From daniel.schroder at gmail.com  Wed Feb 21 07:08:32 2024
From: daniel.schroder at gmail.com (Daniel Schroder)
Date: Wed, 21 Feb 2024 09:08:32 +0200
Subject: Suggest to rename project
In-Reply-To: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>
References: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>
Message-ID: <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>

On Wed, Feb 21, 2024 at 3:26?AM n33kproton via nginx <nginx at freenginx.org>
wrote:

> Maintaining the name "nginx" is importanto IMO to understand the goal of
> the project, but i would suggest something like "libre"
> https://www.gnu.org/philosophy/free-sw.html
> --
>

"ginex" ... for me has a nice ring to it. -daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240221/586540bc/attachment.htm>

From nginx at bgdns.eu  Wed Feb 21 17:22:45 2024
From: nginx at bgdns.eu (Plamen Vasilev)
Date: Wed, 21 Feb 2024 19:22:45 +0200
Subject: Suggest to rename project
In-Reply-To: <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>
References: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>
 <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>
Message-ID: <18dccb0f288.2860.5e635deacd32f876952d45610baf70c0@bgdns.eu>

Hello,

What do you think of the name: 'xngin'?

Best regards,
Plamen Vasilev
BGDNS
On 21 ???????? 2024??. 17:39:40 ?. Daniel Schroder <daniel.schroder at gmail.com> wrote:
> On Wed, Feb 21, 2024 at 3:26?AM n33kproton via nginx <nginx at freenginx.org> wrote:
> Maintaining the name "nginx" is importanto IMO to understand the goal of the project, but i would suggest something like "libre"
> https://www.gnu.org/philosophy/free-sw.html
> --
>
> "ginex" ... for me has a nice ring to it. -daniel
>
> --
> nginx mailing list
> nginx at freenginx.org
> https://freenginx.org/mailman/listinfo/nginx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240221/995b5568/attachment.htm>

From horsecock at airmail.cc  Wed Feb 21 22:13:12 2024
From: horsecock at airmail.cc (hoco)
Date: Wed, 21 Feb 2024 22:13:12 +0000
Subject: Suggest to rename project
In-Reply-To: <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>
References: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>
 <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>
Message-ID: <7e25fdf4f48f6b8788e613c627b0831b@airmail.cc>

gay and uncreative. sorry.

On 2024-02-21 07:08, Daniel Schroder wrote:
> On Wed, Feb 21, 2024 at 3:26?AM n33kproton via nginx
> <nginx at freenginx.org> wrote:
> 
>> Maintaining the name "nginx" is importanto IMO to understand the
>> goal of the project, but i would suggest something like "libre"
>> https://www.gnu.org/philosophy/free-sw.html
>> --
> 
> "ginex" ... for me has a nice ring to it. -daniel


From srebecchi at kameleoon.com  Thu Feb 22 07:14:35 2024
From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=)
Date: Thu, 22 Feb 2024 08:14:35 +0100
Subject: Suggest to rename project
In-Reply-To: <7e25fdf4f48f6b8788e613c627b0831b@airmail.cc>
References: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>
 <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>
 <7e25fdf4f48f6b8788e613c627b0831b@airmail.cc>
Message-ID: <CA+ts6nrf5o3_SfbTuuZPbjwgSqyZkcgCzLLo_zs=ckf_sfPb9g@mail.gmail.com>

nginY like the fork

--
S?bastien

Le mer. 21 f?vr. 2024, 23:13, hoco <horsecock at airmail.cc> a ?crit :

> gay and uncreative. sorry.
>
> On 2024-02-21 07:08, Daniel Schroder wrote:
> > On Wed, Feb 21, 2024 at 3:26?AM n33kproton via nginx
> > <nginx at freenginx.org> wrote:
> >
> >> Maintaining the name "nginx" is importanto IMO to understand the
> >> goal of the project, but i would suggest something like "libre"
> >> https://www.gnu.org/philosophy/free-sw.html
> >> --
> >
> > "ginex" ... for me has a nice ring to it. -daniel
> --
> nginx mailing list
> nginx at freenginx.org
> https://freenginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240222/276360a9/attachment.htm>

From muskrat7 at gmail.com  Fri Feb 23 01:36:43 2024
From: muskrat7 at gmail.com (Matthew)
Date: Thu, 22 Feb 2024 19:36:43 -0600
Subject: Suggest to rename project
In-Reply-To: <CA+ts6nrf5o3_SfbTuuZPbjwgSqyZkcgCzLLo_zs=ckf_sfPb9g@mail.gmail.com>
References: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>
 <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>
 <7e25fdf4f48f6b8788e613c627b0831b@airmail.cc>
 <CA+ts6nrf5o3_SfbTuuZPbjwgSqyZkcgCzLLo_zs=ckf_sfPb9g@mail.gmail.com>
Message-ID: <0a88244f-a7f4-4778-a6c8-f63907be9836@gmail.com>

I kinda like that.

However, I did want to say that nginx.io is much different than 
freenginx.org.

the FreeBSD vs BSD example given is spot on in my opinion.

that said, nginY or freenginY doesn't sound bad IMHO.


On 2/22/24 01:14, S?bastien Rebecchi wrote:
> nginY like the fork
>
> --
> S?bastien
>
> Le mer. 21 f?vr. 2024, 23:13, hoco <horsecock at airmail.cc> a ?crit?:
>
>     gay and uncreative. sorry.
>
>     On 2024-02-21 07:08, Daniel Schroder wrote:
>     > On Wed, Feb 21, 2024 at 3:26?AM n33kproton via nginx
>     > <nginx at freenginx.org> wrote:
>     >
>     >> Maintaining the name "nginx" is importanto IMO to understand the
>     >> goal of the project, but i would suggest something like "libre"
>     >> https://www.gnu.org/philosophy/free-sw.html
>     >> --
>     >
>     > "ginex" ... for me has a nice ring to it. -daniel
>     -- 
>     nginx mailing list
>     nginx at freenginx.org
>     https://freenginx.org/mailman/listinfo/nginx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240222/e1ea82f4/attachment.htm>

From santosventer at chibenga.com  Fri Feb 23 05:52:14 2024
From: santosventer at chibenga.com (Santos Venter Chibenga)
Date: Fri, 23 Feb 2024 07:52:14 +0200
Subject: Suggest to rename project
In-Reply-To: <0a88244f-a7f4-4778-a6c8-f63907be9836@gmail.com>
Message-ID: <857940ec-ee19-4839-b825-4e0b28afd7b6@email.android.com>

An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240223/d053a9b3/attachment.htm>

From fung at v.help  Fri Feb 23 10:02:37 2024
From: fung at v.help (fung at v.help)
Date: Fri, 23 Feb 2024 18:02:37 +0800
Subject: Suggest to rename project (Reza Mahdi)
References: <NU7vhQSGdPuV6gEGa71p7tjChxELHQf66euF_Bxsj397lQ-bLp49jpUOvslHKFk7ALNX4pJ_ABKqRtWWAeKNEZpnQD3Q9mrORULuXrOUN48=@protonmail.com>,
 <CAMvWrAsi+ZoSPw6GBCna+41Dkw135Xp9SjtPt03Oq5nkCE07bw@mail.gmail.com>, 
 <7e25fdf4f48f6b8788e613c627b0831b@airmail.cc>, 
 <CA+ts6nrf5o3_SfbTuuZPbjwgSqyZkcgCzLLo_zs=ckf_sfPb9g@mail.gmail.com>, 
 <0a88244f-a7f4-4778-a6c8-f63907be9836@gmail.com>
Message-ID: <202402231802369789812@v.help>

Why not Xengine?
Alibaba has an open-source product based on Nginx, which named Tengine. The T is Taobao.com.



Conan FUNG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240223/4152f83d/attachment.htm>

From nginx at jkroepke.de  Fri Feb 23 14:57:24 2024
From: nginx at jkroepke.de (=?UTF-8?Q?Jan=2DOtto_Kr=C3=B6pke?=)
Date: Fri, 23 Feb 2024 15:57:24 +0100
Subject: Official docker image
Message-ID: <CAAsn9Yw+g9vCrGLbMaPbJphAwxpfm7mKadTeVeLeSOyYX=qCzQ@mail.gmail.com>

Hello,

thank you for the ongoing development of the nginx web server.

I wanted to inquire whether an official Docker image is on the
roadmap? The sources [1] for the Docker image are licensed under
Apache 2 License and can be used further without any issues.

If assistance is needed, I am happy to help with the implementation,
including assistance in maintaining the images.

[1] https://github.com/nginxinc/docker-nginx-unprivileged


From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Fri Feb 23 17:09:02 2024
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 23 Feb 2024 18:09:02 +0100
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
Message-ID: <20240223180902.297f7b46@fenix>

Hi,

With Chrome dropping the User-Agent in favor of Client Hints, I think
this problem is becoming more and more common: Keep identifying client
details and features on the first connection.

I won't go into details about Client Hints, but just mention that for
some weird (for me) reason, it was decided that the first connection
would always only provide limited client information, and it was up to
the web server to ask for more to be provided in the following
connections to the same hostname.

Apart from wasting connections and round trips by redirecting the
client to (almost) the same URL after having requested the additional
information, there exists a more efficient workaround, which is to
request the additional client information during the TLS handshake, so
that it can actually be provided during the first http request:
https://chromestatus.com/feature/5555544540577792

This doesn't seem to be currently supported in nginx, even when the
underlying TLS library does support ALPS extensions. There was one
attempt made at it two years ago, which can be seen in this commit
titled "Rough sketch of ACCEPT_CH HTTP/2 support through ALPS":
https://github.com/amtunlimited/nginx/commit/e810900a3e4844a9476cad1a9564e0ea7acc4455

I think this something that would make sense to try and include
directly into nginx now that Client Hints are being forced on everyone
by Chrome and Edge. Are there any newer known efforts to support it?

Cheers,
Matthias


From mdounin at mdounin.ru  Fri Feb 23 22:04:32 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sat, 24 Feb 2024 01:04:32 +0300
Subject: Official docker image
In-Reply-To: <CAAsn9Yw+g9vCrGLbMaPbJphAwxpfm7mKadTeVeLeSOyYX=qCzQ@mail.gmail.com>
References: <CAAsn9Yw+g9vCrGLbMaPbJphAwxpfm7mKadTeVeLeSOyYX=qCzQ@mail.gmail.com>
Message-ID: <ZdkWcDnzm1DZRiOB@mdounin.ru>

Hello!

On Fri, Feb 23, 2024 at 03:57:24PM +0100, Jan-Otto Kr?pke via nginx wrote:

> Hello,
> 
> thank you for the ongoing development of the nginx web server.

Thank you for your support.

> I wanted to inquire whether an official Docker image is on the
> roadmap?

Might be at some later point.

Also, I'm not sure it's actually needed: once we'll have packages 
available in various OSs, it would be trivial to create an image 
from a vanilla OS one.

> The sources [1] for the Docker image are licensed under
> Apache 2 License and can be used further without any issues.
> 
> If assistance is needed, I am happy to help with the implementation,
> including assistance in maintaining the images.
> 
> [1] https://github.com/nginxinc/docker-nginx-unprivileged

Strictly speaking, I would rather object adding Apache2-licensed 
code to the project: it is not compatible with the BSD license 
nginx (and freenginx) uses.

-- 
Maxim Dounin
http://mdounin.ru/


From mdounin at mdounin.ru  Sat Feb 24 00:02:35 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sat, 24 Feb 2024 03:02:35 +0300
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
In-Reply-To: <20240223180902.297f7b46@fenix>
References: <20240223180902.297f7b46@fenix>
Message-ID: <ZdkyGz5O2vWhROyV@mdounin.ru>

Hello!

On Fri, Feb 23, 2024 at 06:09:02PM +0100, Matthias Saou wrote:

> With Chrome dropping the User-Agent in favor of Client Hints, I think
> this problem is becoming more and more common: Keep identifying client
> details and features on the first connection.

Any specific details about "dropping the User-Agent"?  From 
https://developers.google.com/privacy-sandbox/protections/user-agent 
it looks like User-Agent is still here, provides basic information 
about client browser version and platform, and it is not going 
anywhere.

> I won't go into details about Client Hints, but just mention that for
> some weird (for me) reason, it was decided that the first connection
> would always only provide limited client information, and it was up to
> the web server to ask for more to be provided in the following
> connections to the same hostname.
> 
> Apart from wasting connections and round trips by redirecting the
> client to (almost) the same URL after having requested the additional
> information, there exists a more efficient workaround, which is to
> request the additional client information during the TLS handshake, so
> that it can actually be provided during the first http request:
> https://chromestatus.com/feature/5555544540577792
> 
> This doesn't seem to be currently supported in nginx, even when the
> underlying TLS library does support ALPS extensions. There was one
> attempt made at it two years ago, which can be seen in this commit
> titled "Rough sketch of ACCEPT_CH HTTP/2 support through ALPS":
> https://github.com/amtunlimited/nginx/commit/e810900a3e4844a9476cad1a9564e0ea7acc4455
> 
> I think this something that would make sense to try and include
> directly into nginx now that Client Hints are being forced on everyone
> by Chrome and Edge. Are there any newer known efforts to support it?

Note that the draft-davidben-http-client-hint-reliability draft 
referenced in the Chrome feature (and the user-agent page) expired 
in 2021, and the same applies to the vvv-tls-alps and 
draft-vvv-httpbis-alps drafts.  This makes it highly unlikely to 
be ever supported by OpenSSL.

OTOH, if draft-davidben-http-client-hint-reliability is supported, 
the Critical-CH header should make it trivial (though potentially 
suboptimal, compared to ALPS) to request any specific hints if 
they are actually needed.  Without ALPS implemented, using the 
Critical-CH header might be a good alternative.

-- 
Maxim Dounin
http://mdounin.ru/


From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sun Feb 25 19:18:56 2024
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sun, 25 Feb 2024 20:18:56 +0100
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
In-Reply-To: <ZdkyGz5O2vWhROyV@mdounin.ru>
References: <20240223180902.297f7b46@fenix>
	<ZdkyGz5O2vWhROyV@mdounin.ru>
Message-ID: <20240225201856.2b86f1b8@fenix>

Hi,

On Sat, 24 Feb 2024 03:02:35 +0300
Maxim Dounin <mdounin at mdounin.ru> wrote:

> Any specific details about "dropping the User-Agent"?  From 
> https://developers.google.com/privacy-sandbox/protections/user-agent 
> it looks like User-Agent is still here, provides basic information 
> about client browser version and platform, and it is not going 
> anywhere.

I got it wrong. Looks like all browsers are going to be Netscape 6.1
until the end of times! :-)

My particular issue is actually with what is now sometimes missing from
the User-Agent by default, such as the device brand (Samsung,
Xiaomi...) or the OS version (Windows 10 or 11...).

If you know you need this data, then having a mechanism to keep having
it included in the first http client response would make things a lot
easier.

> Note that the draft-davidben-http-client-hint-reliability draft 
> referenced in the Chrome feature (and the user-agent page) expired 
> in 2021, and the same applies to the vvv-tls-alps and 
> draft-vvv-httpbis-alps drafts.  This makes it highly unlikely to 
> be ever supported by OpenSSL.
> 
> OTOH, if draft-davidben-http-client-hint-reliability is supported, 
> the Critical-CH header should make it trivial (though potentially 
> suboptimal, compared to ALPS) to request any specific hints if 
> they are actually needed.  Without ALPS implemented, using the 
> Critical-CH header might be a good alternative.

Thanks for the pointer! I just read up on
https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability
and the Critical-CH header probably wouldn't be suitable for our use
case (since it will typically trigger a second client connection), but
the ACCEPT_CH frame definitely would, especially given all these recent
clients would be connecting over HTTP/2 or newer. But that draft seems
to also have expired in 2021, no?

So it seems like as of right now, with recent Chrome & Edge clients,
there is no way to have nginx receive more than the 3 default client
hints during the first client http connection?

Cheers,
Matthias


From mdounin at mdounin.ru  Sun Feb 25 22:34:31 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 26 Feb 2024 01:34:31 +0300
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
In-Reply-To: <20240225201856.2b86f1b8@fenix>
References: <20240223180902.297f7b46@fenix> <ZdkyGz5O2vWhROyV@mdounin.ru>
 <20240225201856.2b86f1b8@fenix>
Message-ID: <ZdvAdz_7-RRjampg@mdounin.ru>

Hello!

On Sun, Feb 25, 2024 at 08:18:56PM +0100, Matthias Saou wrote:

> Hi,
> 
> On Sat, 24 Feb 2024 03:02:35 +0300
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Any specific details about "dropping the User-Agent"?  From 
> > https://developers.google.com/privacy-sandbox/protections/user-agent 
> > it looks like User-Agent is still here, provides basic information 
> > about client browser version and platform, and it is not going 
> > anywhere.
> 
> I got it wrong. Looks like all browsers are going to be Netscape 6.1
> until the end of times! :-)

Well, not really, but the only meaningful information included now 
is:

- browser name and version (also in Sec-CH-UA);
- mobile flag (also in Sec-CH-UA-Mobile);
- platform name (also in Sec-CH-UA-Platform).

This is a lot, and I tend to think this should be enough for most 
sites.  Still, it is certainly not the all information the browser 
can provide.

> My particular issue is actually with what is now sometimes missing from
> the User-Agent by default, such as the device brand (Samsung,
> Xiaomi...) or the OS version (Windows 10 or 11...).
> 
> If you know you need this data, then having a mechanism to keep having
> it included in the first http client response would make things a lot
> easier.

Yep, device brand and OS version are not available by default now.

> > Note that the draft-davidben-http-client-hint-reliability draft 
> > referenced in the Chrome feature (and the user-agent page) expired 
> > in 2021, and the same applies to the vvv-tls-alps and 
> > draft-vvv-httpbis-alps drafts.  This makes it highly unlikely to 
> > be ever supported by OpenSSL.
> > 
> > OTOH, if draft-davidben-http-client-hint-reliability is supported, 
> > the Critical-CH header should make it trivial (though potentially 
> > suboptimal, compared to ALPS) to request any specific hints if 
> > they are actually needed.  Without ALPS implemented, using the 
> > Critical-CH header might be a good alternative.
> 
> Thanks for the pointer! I just read up on
> https://datatracker.ietf.org/doc/html/draft-davidben-http-client-hint-reliability
> and the Critical-CH header probably wouldn't be suitable for our use
> case (since it will typically trigger a second client connection), but
> the ACCEPT_CH frame definitely would, especially given all these recent
> clients would be connecting over HTTP/2 or newer. But that draft seems
> to also have expired in 2021, no?

Yep, the particular Chrome feature is based on this draft, and it 
expired in 2021.

The difference between the Critical-CH header and the ACCEPT_CH 
frame sent via ALPS is that ALPS information is sent to the 
browser before the first request, so the browser is able to 
provide requested headers in the first request.  With the 
Critical-CH header, the browser instead sees the list of requested 
headers with the first response.  But it's browser's 
responsibility to retry the request with appropriate headers 
provided, so there is no need to do anything on the server side.  

That is, the Critical-CH header implies additional HTTP request, 
while ACCEPT_CH sent via ALPS implies additional information sent 
during SSL handshake.  ALPS-based negotiation might be more 
optimal, but it's certainly a layering violation, and hence 
somewhat questionable solution (I haven't followed IETF 
discussions about the drafts, but I guess that's the main concern 
here, and might be the reason why these drafts expired).

As far as I understand, the Critical-CH header should be good 
enough for most use cases, except might be for statistical 
counters which often use just one HTTP request, and therefore 
another one will be a huge change.

If you are able to share, it would be great if you'll provide more 
details about your use case.

> So it seems like as of right now, with recent Chrome & Edge clients,
> there is no way to have nginx receive more than the 3 default client
> hints during the first client http connection?

Yes, there is no support now (except the patch you've mentioned).

-- 
Maxim Dounin
http://mdounin.ru/


From admin at rzmahdi.ir  Mon Feb 26 07:43:55 2024
From: admin at rzmahdi.ir (Reza Mahdi)
Date: Mon, 26 Feb 2024 11:13:55 +0330
Subject: Feature implementation policy
Message-ID: <CZEUCEDQ1G3V.1GHJG18BW7UXW@rzmahdi.ir>

Hi

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?

--
Reza Mahdi



From mdounin at mdounin.ru  Mon Feb 26 16:10:39 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 26 Feb 2024 19:10:39 +0300
Subject: Feature implementation policy
In-Reply-To: <CZEUCEDQ1G3V.1GHJG18BW7UXW@rzmahdi.ir>
References: <CZEUCEDQ1G3V.1GHJG18BW7UXW@rzmahdi.ir>
Message-ID: <Zdy3_-J4MJltpwH3@mdounin.ru>

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/


From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Mon Feb 26 17:13:42 2024
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Mon, 26 Feb 2024 18:13:42 +0100
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
In-Reply-To: <ZdvAdz_7-RRjampg@mdounin.ru>
References: <20240223180902.297f7b46@fenix> <ZdkyGz5O2vWhROyV@mdounin.ru>
 <20240225201856.2b86f1b8@fenix> <ZdvAdz_7-RRjampg@mdounin.ru>
Message-ID: <20240226181342.47aecde3@fenix>

Hi,

On Mon, 26 Feb 2024 01:34:31 +0300
Maxim Dounin <mdounin at mdounin.ru> wrote:

> [...]
> As far as I understand, the Critical-CH header should be good 
> enough for most use cases, except might be for statistical 
> counters which often use just one HTTP request, and therefore 
> another one will be a huge change.
> 
> If you are able to share, it would be great if you'll provide more 
> details about your use case.

A very simple use case is basic contextual ads. Presenting a somewhat
targeted ad with no user information, no session cookie, nothing more
than what a single http request provides. This means using in real time
things like the referer header, the accepted languages and the
user-agent string.

The Mobile and Platform UA-CH headers do still provide the most
critical information for this, so it's more about the corner cases: If
an Android app is only compatible with Android 10 and up, you don't
want to be advertising to users of Android 9 and below.

Delivering such a targeted ad currently requires only one http request.
But with a reduced User-Agent and the Platform-Version CH header
missing, it's no longer possible. What can be tried is:

* Replying with the Critical-CH header. The client might then re-request
  an ad... or not, which will skew things quite a bit.
* Redirect the client in order to request the header. You expose
  yourself to potential infinite redirection bugs and use more
  resources because of the extra http request.

> > So it seems like as of right now, with recent Chrome & Edge clients,
> > there is no way to have nginx receive more than the 3 default client
> > hints during the first client http connection?
> 
> Yes, there is no support now (except the patch you've mentioned).

I *really* wanted to avoid having to dig that patch up and potentially
have to switch TLS library just to make this work! :-)

I also wanted to avoid having to implement a redirection in nginx, but
I think I will have to also try something like this out in case it does
end up working reliably:

* If our parameter indicating we already redirected is missing,
* And the UA-CH Mobile header is present,
* And the UA-CH Platform-Version header is absent,
* Then redirect to the same URL but appending our parameter indicating
  we already redirected.

This way it could potentially still achieve triggering a single request
to the backend nginx is using, that would include the Platform-Version
if the client agreed to provide it.

Cheers,
Matthias


From Jan at teunis.be  Tue Feb 27 15:18:52 2024
From: Jan at teunis.be (Jan @ Teunis.be)
Date: Tue, 27 Feb 2024 16:18:52 +0100
Subject: Logo Proposal
Message-ID: <CAFhSOHq+Q73DO6do2BfnFzMkM-Myyqw+MOP3fdfFxH91ntg3sw@mail.gmail.com>

Hey,

Don't know if this is the right place to show this. Don't know who decides
about this.
But I've made a more modern logo for FreeNginx

View it on the following link:
https://i.postimg.cc/LXG3Vj2F/image.png

Let me know what you think.


Kind regards,
    Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240227/11119ce0/attachment.htm>

From ceau74 at gmail.com  Tue Feb 27 17:03:53 2024
From: ceau74 at gmail.com (Cesar L. C.)
Date: Tue, 27 Feb 2024 12:03:53 -0500
Subject: Logo Proposal
In-Reply-To: <CAFhSOHq+Q73DO6do2BfnFzMkM-Myyqw+MOP3fdfFxH91ntg3sw@mail.gmail.com>
References: <CAFhSOHq+Q73DO6do2BfnFzMkM-Myyqw+MOP3fdfFxH91ntg3sw@mail.gmail.com>
Message-ID: <CANrSF2tO4jzMy8a53gyDBCdM7LQdAvuoxu885__FOeU0BS3ecQ@mail.gmail.com>

I liked it, it's so cool, it's a nice design.
[image: image.png]
Note:
Should be to consider to change the name to "SuperServerX". The word "free"
should be not have much relevance, should be show a total change.

Regards.


On Tue, 27 Feb 2024 at 10:19, Jan @ Teunis.be <Jan at teunis.be> wrote:

> Hey,
>
> Don't know if this is the right place to show this. Don't know who decides
> about this.
> But I've made a more modern logo for FreeNginx
>
> View it on the following link:
> https://i.postimg.cc/LXG3Vj2F/image.png
>
> Let me know what you think.
>
>
> Kind regards,
>     Jan
>
>
> --
> nginx mailing list
> nginx at freenginx.org
> https://freenginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20240227/cd42be92/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14961 bytes
Desc: not available
URL: <http://freenginx.org/pipermail/nginx/attachments/20240227/cd42be92/attachment.png>

From mdounin at mdounin.ru  Tue Feb 27 19:44:34 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 27 Feb 2024 22:44:34 +0300
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
In-Reply-To: <20240226181342.47aecde3@fenix>
References: <20240223180902.297f7b46@fenix> <ZdkyGz5O2vWhROyV@mdounin.ru>
 <20240225201856.2b86f1b8@fenix> <ZdvAdz_7-RRjampg@mdounin.ru>
 <20240226181342.47aecde3@fenix>
Message-ID: <Zd47ouTYjJhW2UAy@mdounin.ru>

Hello!

On Mon, Feb 26, 2024 at 06:13:42PM +0100, Matthias Saou wrote:

> On Mon, 26 Feb 2024 01:34:31 +0300
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > [...]
> > As far as I understand, the Critical-CH header should be good 
> > enough for most use cases, except might be for statistical 
> > counters which often use just one HTTP request, and therefore 
> > another one will be a huge change.
> > 
> > If you are able to share, it would be great if you'll provide more 
> > details about your use case.
> 
> A very simple use case is basic contextual ads. Presenting a somewhat
> targeted ad with no user information, no session cookie, nothing more
> than what a single http request provides. This means using in real time
> things like the referer header, the accepted languages and the
> user-agent string.
> 
> The Mobile and Platform UA-CH headers do still provide the most
> critical information for this, so it's more about the corner cases: If
> an Android app is only compatible with Android 10 and up, you don't
> want to be advertising to users of Android 9 and below.

Thanks for the use case description.

> Delivering such a targeted ad currently requires only one http request.

You mean - only one http request, assuming the javascript code to 
show ads is previously loaded from another domain?  Note that 
loading the code from the same origin with appropriate Accept-CH 
header might be the way to go.

> But with a reduced User-Agent and the Platform-Version CH header
> missing, it's no longer possible. What can be tried is:
> 
> * Replying with the Critical-CH header. The client might then re-request
>   an ad... or not, which will skew things quite a bit.
> * Redirect the client in order to request the header. You expose
>   yourself to potential infinite redirection bugs and use more
>   resources because of the extra http request.

Yep, Critical-CH is, basically, a simpler alternative to 
error-prone redirects with Accept-CH.  It doesn't save a backend 
request though, in case the first response is not really used due 
to re-request with critical hints provided.

Another alternative might be to use Accept-CH, and do not show 
versions-specific ads to clients without platform version 
provided.  That is, such ads will be shown only to clients which 
did more than one request.  Might be good enough for a corner 
case.

> > > So it seems like as of right now, with recent Chrome & Edge clients,
> > > there is no way to have nginx receive more than the 3 default client
> > > hints during the first client http connection?
> > 
> > Yes, there is no support now (except the patch you've mentioned).
> 
> I *really* wanted to avoid having to dig that patch up and potentially
> have to switch TLS library just to make this work! :-)
> 
> I also wanted to avoid having to implement a redirection in nginx, but
> I think I will have to also try something like this out in case it does
> end up working reliably:
> 
> * If our parameter indicating we already redirected is missing,
> * And the UA-CH Mobile header is present,
> * And the UA-CH Platform-Version header is absent,
> * Then redirect to the same URL but appending our parameter indicating
>   we already redirected.
> 
> This way it could potentially still achieve triggering a single request
> to the backend nginx is using, that would include the Platform-Version
> if the client agreed to provide it.

Yep, looks correct and safe enough, in case the goal is to save 
backend requests.

-- 
Maxim Dounin
http://mdounin.ru/


From noc at 199693.xyz  Tue Feb 27 20:10:33 2024
From: noc at 199693.xyz (AS199693)
Date: Wed, 28 Feb 2024 01:40:33 +0530
Subject: Logo Proposal (noc@199693.xyz)
In-Reply-To: <mailman.133.1709063076.8028.nginx@freenginx.org>
References: <mailman.133.1709063076.8028.nginx@freenginx.org>
Message-ID: <5BCBBB95-9579-42F4-A898-CCEECBB215F7@199693.xyz>

Why not name it nginy? 
Swap out the x for a y?
Or perhaps xengine?

SuperServerX seems almost something a 9 year old kid would say. Not like I am not 15, but still.

(This is my first time replying to a mailing list, please consider my mistakes)

Am 28. Februar 2024 01:14:36 GMT+05:30 schrieb nginx-request at freenginx.org:
>Send nginx mailing list submissions to
>	nginx at freenginx.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://freenginx.org/mailman/listinfo/nginx
>or, via email, send a message with subject or body 'help' to
>	nginx-request at freenginx.org
>
>You can reach the person managing the list at
>	nginx-owner at freenginx.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of nginx digest..."
>
>
>Today's Topics:
>
>   1. Logo Proposal (Jan @ Teunis.be)
>   2. Re: Logo Proposal (Cesar L. C.)
>   3. Re: Nginx support for TLS ALPS extension for ACCEPT_CH?
>      (Maxim Dounin)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 27 Feb 2024 16:18:52 +0100
>From: "Jan @ Teunis.be" <Jan at teunis.be>
>To: nginx at freenginx.org
>Subject: Logo Proposal
>Message-ID:
>	<CAFhSOHq+Q73DO6do2BfnFzMkM-Myyqw+MOP3fdfFxH91ntg3sw at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hey,
>
>Don't know if this is the right place to show this. Don't know who decides
>about this.
>But I've made a more modern logo for FreeNginx
>
>View it on the following link:
>https://i.postimg.cc/LXG3Vj2F/image.png
>
>Let me know what you think.
>
>
>Kind regards,
>    Jan
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://freenginx.org/pipermail/nginx/attachments/20240227/11119ce0/attachment-0001.htm>
>
>------------------------------
>
>Message: 2
>Date: Tue, 27 Feb 2024 12:03:53 -0500
>From: "Cesar L. C." <ceau74 at gmail.com>
>To: free nginx mailing list <nginx at freenginx.org>
>Subject: Re: Logo Proposal
>Message-ID:
>	<CANrSF2tO4jzMy8a53gyDBCdM7LQdAvuoxu885__FOeU0BS3ecQ at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>I liked it, it's so cool, it's a nice design.
>[image: image.png]
>Note:
>Should be to consider to change the name to "SuperServerX". The word "free"
>should be not have much relevance, should be show a total change.
>
>Regards.
>
>
>On Tue, 27 Feb 2024 at 10:19, Jan @ Teunis.be <Jan at teunis.be> wrote:
>
>> Hey,
>>
>> Don't know if this is the right place to show this. Don't know who decides
>> about this.
>> But I've made a more modern logo for FreeNginx
>>
>> View it on the following link:
>> https://i.postimg.cc/LXG3Vj2F/image.png
>>
>> Let me know what you think.
>>
>>
>> Kind regards,
>>     Jan
>>
>>
>> --
>> nginx mailing list
>> nginx at freenginx.org
>> https://freenginx.org/mailman/listinfo/nginx
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://freenginx.org/pipermail/nginx/attachments/20240227/cd42be92/attachment-0001.htm>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: image.png
>Type: image/png
>Size: 14961 bytes
>Desc: not available
>URL: <http://freenginx.org/pipermail/nginx/attachments/20240227/cd42be92/attachment-0001.png>
>
>------------------------------
>
>Message: 3
>Date: Tue, 27 Feb 2024 22:44:34 +0300
>From: Maxim Dounin <mdounin at mdounin.ru>
>To: free nginx mailing list <nginx at freenginx.org>
>Subject: Re: Nginx support for TLS ALPS extension for ACCEPT_CH?
>Message-ID: <Zd47ouTYjJhW2UAy at mdounin.ru>
>Content-Type: text/plain; charset=us-ascii
>
>Hello!
>
>On Mon, Feb 26, 2024 at 06:13:42PM +0100, Matthias Saou wrote:
>
>> On Mon, 26 Feb 2024 01:34:31 +0300
>> Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 
>> > [...]
>> > As far as I understand, the Critical-CH header should be good 
>> > enough for most use cases, except might be for statistical 
>> > counters which often use just one HTTP request, and therefore 
>> > another one will be a huge change.
>> > 
>> > If you are able to share, it would be great if you'll provide more 
>> > details about your use case.
>> 
>> A very simple use case is basic contextual ads. Presenting a somewhat
>> targeted ad with no user information, no session cookie, nothing more
>> than what a single http request provides. This means using in real time
>> things like the referer header, the accepted languages and the
>> user-agent string.
>> 
>> The Mobile and Platform UA-CH headers do still provide the most
>> critical information for this, so it's more about the corner cases: If
>> an Android app is only compatible with Android 10 and up, you don't
>> want to be advertising to users of Android 9 and below.
>
>Thanks for the use case description.
>
>> Delivering such a targeted ad currently requires only one http request.
>
>You mean - only one http request, assuming the javascript code to 
>show ads is previously loaded from another domain?  Note that 
>loading the code from the same origin with appropriate Accept-CH 
>header might be the way to go.
>
>> But with a reduced User-Agent and the Platform-Version CH header
>> missing, it's no longer possible. What can be tried is:
>> 
>> * Replying with the Critical-CH header. The client might then re-request
>>   an ad... or not, which will skew things quite a bit.
>> * Redirect the client in order to request the header. You expose
>>   yourself to potential infinite redirection bugs and use more
>>   resources because of the extra http request.
>
>Yep, Critical-CH is, basically, a simpler alternative to 
>error-prone redirects with Accept-CH.  It doesn't save a backend 
>request though, in case the first response is not really used due 
>to re-request with critical hints provided.
>
>Another alternative might be to use Accept-CH, and do not show 
>versions-specific ads to clients without platform version 
>provided.  That is, such ads will be shown only to clients which 
>did more than one request.  Might be good enough for a corner 
>case.
>
>> > > So it seems like as of right now, with recent Chrome & Edge clients,
>> > > there is no way to have nginx receive more than the 3 default client
>> > > hints during the first client http connection?
>> > 
>> > Yes, there is no support now (except the patch you've mentioned).
>> 
>> I *really* wanted to avoid having to dig that patch up and potentially
>> have to switch TLS library just to make this work! :-)
>> 
>> I also wanted to avoid having to implement a redirection in nginx, but
>> I think I will have to also try something like this out in case it does
>> end up working reliably:
>> 
>> * If our parameter indicating we already redirected is missing,
>> * And the UA-CH Mobile header is present,
>> * And the UA-CH Platform-Version header is absent,
>> * Then redirect to the same URL but appending our parameter indicating
>>   we already redirected.
>> 
>> This way it could potentially still achieve triggering a single request
>> to the backend nginx is using, that would include the Platform-Version
>> if the client agreed to provide it.
>
>Yep, looks correct and safe enough, in case the goal is to save 
>backend requests.
>

-- 
Bihaan Sen
AS199693
199693.xyz


From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Tue Feb 27 22:53:30 2024
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Tue, 27 Feb 2024 23:53:30 +0100
Subject: Nginx support for TLS ALPS extension for ACCEPT_CH?
In-Reply-To: <Zd47ouTYjJhW2UAy@mdounin.ru>
References: <20240223180902.297f7b46@fenix> <ZdkyGz5O2vWhROyV@mdounin.ru>
 <20240225201856.2b86f1b8@fenix> <ZdvAdz_7-RRjampg@mdounin.ru>
 <20240226181342.47aecde3@fenix> <Zd47ouTYjJhW2UAy@mdounin.ru>
Message-ID: <20240227235330.7970bf5e@fenix>

Hi,

On Tue, 27 Feb 2024 22:44:34 +0300
Maxim Dounin <mdounin at mdounin.ru> wrote:

> > Delivering such a targeted ad currently requires only one http
> > request.
> 
> You mean - only one http request, assuming the javascript code to 
> show ads is previously loaded from another domain?  Note that 
> loading the code from the same origin with appropriate Accept-CH 
> header might be the way to go.

Unfortunately, if there's some related js included with all this, it's
100% static and best served from a CDN. The "dynamic" request goes to a
different hostname, to avoid being proxied for little gain through the
CDN. But returning the Accept-CH from the CDN alongside that js would
make a stronger case for considering doing that proxying. Thanks for
the suggestion!

> > I also wanted to avoid having to implement a redirection in nginx,
> > but I think I will have to also try something like this out in case
> > it does end up working reliably:
> > 
> > * If our parameter indicating we already redirected is missing,
> > * And the UA-CH Mobile header is present,
> > * And the UA-CH Platform-Version header is absent,
> > * Then redirect to the same URL but appending our parameter
> > indicating we already redirected.
> > 
> > This way it could potentially still achieve triggering a single
> > request to the backend nginx is using, that would include the
> > Platform-Version if the client agreed to provide it.
> 
> Yep, looks correct and safe enough, in case the goal is to save 
> backend requests.

Thanks for confirming! This will surely be the workaround that will be
tried first.

Matthias


From mdounin at mdounin.ru  Tue Feb 27 23:24:13 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 28 Feb 2024 02:24:13 +0300
Subject: Logo Proposal
In-Reply-To: <CAFhSOHq+Q73DO6do2BfnFzMkM-Myyqw+MOP3fdfFxH91ntg3sw@mail.gmail.com>
References: <CAFhSOHq+Q73DO6do2BfnFzMkM-Myyqw+MOP3fdfFxH91ntg3sw@mail.gmail.com>
Message-ID: <Zd5vHbgK4b-35-CY@mdounin.ru>

Hello!

On Tue, Feb 27, 2024 at 04:18:52PM +0100, Jan @ Teunis.be wrote:

> Hey,
> 
> Don't know if this is the right place to show this. Don't know who decides
> about this.
> But I've made a more modern logo for FreeNginx
> 
> View it on the following link:
> https://i.postimg.cc/LXG3Vj2F/image.png
> 
> Let me know what you think.

Jan, thanks for the logo, it looks pretty cool.

Right now I'm fine with the existing logo as on the site, as it is 
simple and easy to change if needed.  I'll keep in mind there is a 
nice alternative in case we'll decide to change the logo.

-- 
Maxim Dounin
http://mdounin.ru/