[PATCH] New directive and variable to log module

[Fabiano Furtado]

Hi!

On Sun, Apr 19, 2026 at 2:51 PM Maxim Dounin wrote:
>
> Hello!
>
> On Sat, Apr 18, 2026 at 06:40:43PM -0300, Fabiano Furtado wrote:
>
> > Dear freenginx developers,
> >
> > I would appreciate it if you could take a look at this patch and
> > provide your feedback or suggestions for improvements, or let me know
> > if you think it would be a valuable addition to the project.
> >
> > This patch introduces the new "log_tag" directive to freenginx, which
> > allows you to define a custom tag for each http, server or location
> > block. This tag is then referenced using the "$tag" variable within
> > the "log_format" directive, making it easier to filter and match logs,
> > especially in configurations with many location blocks or complex ones
> > using regular expressions.
> >
> > As an alternative, the directive and variable could be named as:
> >   * "log_label" / "$label"
> >   * "log_id" / "$id"
>
> First of all, I would like to note that there should be no
> log-specific variables.  All variables should be universally
> supported by the generic variables infrastructure, without
> exceptions.  In particular, this is an important factor to
> properly support alternative logging modules.
>
> Last log-specific variables were changed to universally supported
> ones in nginx 1.3.12 in Feb 2013
> (http://freenginx.org/hg/nginx/rev/829cc5872186).  Variables
> handled directly by the access log module exist only as an
> optimization and exactly match corresponding generic variables.
>
> As for the idea of introducing a (generic) variable to identify
> locations used to handle the request, I don't have a strong
> opinion here.  If I understand the use case correctly, my personal
> approach would be to use "set" to construct appropriate variables
> while in progress, and rewrite the configuration to something
> manageable as soon as possible.

First of all, thank you for the explanations.

I tested the "set" directive and it worked well. However, why doesn’t
it have NGX_HTTP_MAIN_CONF visibility in its context? I believe it
could be used inside the "http{}" block with a default value for all
"server{}" blocks.

Thanks in advance.
Fabiano Furtado