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
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].
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
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
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-conditional _return_
> directive vs nest
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-
