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-requ...@freenginx.org: >Send nginx mailing list submissions to > nginx@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-requ...@freenginx.org > >You can reach the person managing the list at > nginx-ow...@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" <j...@teunis.be> >To: nginx@freenginx.org >Subject: Logo Proposal >Message-ID: > <cafhsohq+q73do6do2bfnfzmkm-myyqw+mop3fdffxh91ntg...@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." <cea...@gmail.com> >To: free nginx mailing list <nginx@freenginx.org> >Subject: Re: Logo Proposal >Message-ID: > <canrsf2to4jzmy8a53gydbcdm7lqdavuoxu885__foeu0bs3...@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 <j...@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@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 <mdou...@mdounin.ru> >To: free nginx mailing list <nginx@freenginx.org> >Subject: Re: Nginx support for TLS ALPS extension for ACCEPT_CH? >Message-ID: <zd47outyjjhw2...@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 <mdou...@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 -- nginx mailing list nginx@freenginx.org https://freenginx.org/mailman/listinfo/nginx
