On Sat, Jul 30, 2022 at 05:13:52AM +0900, nanaya wrote:

Hi there,

> I have a few questions about the real ip module (tried on nginx/1.22.0):

I can see similar curious behaviour to what you report.

I'm not sure if it is "intended behaviour", or "that kind of variation
was never considered" -- either way, you'll likely need a code change
to achieve what you want, unless you can adapt your config to what the
current code provides.

> 1. is there no way to reset the list of `set_real_ip_from` for a specific subsection? For example to have a completely different set of trusted addresses for a specific server
>

That one seems to work for me.

set_real_ip_from at http level, with another value at server level. A
server without the second value uses the http-level one; a server with
the second value uses that value only.

Can you show a sample config that does not work?

> 2. does setting `real_ip_header '';` in a section effectively disable the module for the section?

I don't see that it does; and I don't see that the documentation says
that it would. So I'd say "no, it does not".

> 3. documentation says `real_ip_header` is allowed in location block but it doesn't seem to do anything?
>

This one is a bit subtle.

As far as I can see, if there is no value at http or server level,
then the value at location level is effectively used. But if there is
something at http or server level, then the value at location level is
effectively ignored.

That's not the usual way that nginx directive inheritance works; my guess
in this case is that the replacement-ip-address-variable is set at the
outermost level, and then in the inner level, the variable is seen to
have a value and that value is re-used rather than re-calculated.

> This still uses address from X-Real-Ip instead of X-Other for allow check and log:
>

From playing with 1.22, if you want different real_ip_header header
values to apply in different locations, you probably need to only set
the directive at location level -- and set it in every location where
you want it.

Basically -- ensure that there is nothing to be inherited into a section
that wants to have a specific value set, so that the curious effective
inheritance behaviour of this directive does not take effect.

That might let you get the end result that you want today; if you want
a future version to work in "the expected" fashion, then you'll want to
convince someone that the cost of maintaining the new code to do that
is less than the benefit of being able to do that.

Cheers,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org