[PATCH] New directive and variable to log module

[Maxim Dounin]

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.

-- 
Maxim Dounin
http://mdounin.ru/