Re: Unsubscribe from Nginx Project

To unsubscribe send an email to nginx-devel-le...@nginx.org Sergey Brester --Stop the pathetic Hypocrisy 24.02.2022 13:51, Ranier Vilela wrote: > Hi, > > Please unsubscribe me from the Nginx mail list. > > Ranier Vilela > --Stop the War. > > __

Re: ngx_log_error, ngx_slprintf signal safe

Hi, Function ngx_slprintf is conditionally async-signal safe (unless you'd use the same buffer, supplied as first argument, or free such buffer or some of the arguments in signal handler, because the function is not atomic and can be interrupted by a signal). However regarding the function n

Re: Special character # in url

Hi, firstly please don't use nginx-devel for such questions, this is a developer mailing list and reserved for developers only purposes. Furthermore it is not nginx related question at all. The browsers handle #-chars as an internal jump to the anchor by ID of element on page, so nginx (or w

Re: announcing freenginx.org

Hi Maxim, it is pity to hear such news... I have few comments and questions about, which I enclosed inline below... Regards, Serg. 14.02.2024 19:03, 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 reach

Precedence return directive and nested locations

Hi, it seems that the question of precedence of non-conditional _return_ directive vs nested _location_s is not really clear, or rather some constellations (like fallback) are impossible or else the configuration may look weird. For instance: server { server_name ...; location ~ ^/(some-

Re: Precedence return directive and nested locations

OK, regarding the "fallback" location, this one can be used (empty - shortest match): location "" { return 444; } Regards, Serg. 24.08.2022 19:38, Sergey Brester via nginx-devel wrote: > Hi, > > it seems that the question of precedence of non-conditi

[PATCH] fix weakness by logging of broken header by incorect proxy protocol (IDS/IPS/LOG-analysis)

Hi, below is a patch to fix a weakness by logging of broken header by incorrect proxy protocol. If some service (IDS/IPS) analyzing or monitoring log-file, regularly formatted lines may be simply confused with lines written not escaped directly from buffer supplied from foreign source. Not t

Re: [PATCH] fix weakness by logging of broken header by incorect proxy protocol (IDS/IPS/LOG-analysis)

Sure, this was also my first intention. Just after all I thought the whole buffer could be better in order to provide a possibility to debug for someone searching for a bug. But there are another aids that would help, so indeed let it be so. As for the rest, well it is surely a subject of dif

Re: Non blocking delay in header filters

Well, it is impossible if you'd use some memory blocks allocated by nginx within main request. The memory allocated inside the request is released on request end. An example how one can implement non-blocking delay can you see in https://github.com/openresty/echo-nginx-module#echo_sleep [2].

Re: Core: Avoid memcpy from NULL

Enclosed few thoughts to the subject: - since it is very rare situation that one needs only a memcpy without to know whether previous alloc may fail (e. g. some of pointers were NULL), me too thinks that the caller should be responsible for the check. So I would not extend ngx_memcpy or ng