[PATCH] New directive and variable to log module

[Fabiano Furtado]

Hi!

On Wed, Apr 22, 2026 at 9:18 PM Maxim Dounin wrote:
>
> Hello!
>
> On Wed, Apr 22, 2026 at 01:33:52PM -0300, Fabiano Furtado wrote:
>
> > 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.
>
> The "set" directive is a rewrite module instruction, and it
> defines an action which is executed when rewrite instructions are
> executed, see here for details:
>
> https://freenginx.org/en/docs/http/ngx_http_rewrite_module.html
>
> That is, the directive itself is not about providing a default
> value, it's about changing a variable.  And it is only available in
> contexts where rewrite instructions are expected to appear.
>
> If you need some default value and not happy with an empty string
> as the default, consider using a map to provide one, for example:
>
>     map "" $tag {
>         default "foo";
>     }
>
> This will define a variable with "foo" as a default value, and it
> will be possible to change the variable with "set" where
> appropriate.

Thanks for this default map config. It helped me a lot.

Fabiano Furtado