Logo Proposal (noc at 199693.xyz)

Tue Feb 27 20:10:33 UTC 2024

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