On 01/04/2020 06:56, Frank Tornack wrote:
> Am Dienstag, den 31.03.2020, 15:47 +0100 schrieb Mark Thomas:
>> On 31/03/2020 07:26, Frank Tornack wrote:
<snip/>
>>> We used the following configuration for access logging and remote
>>> valve:
>>> <Valve className="org.apache.catalina.valves.RemoteIpValve"
>>> internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9
>>> " remoteIpHeader="X-Forwarded-For" />
>>
>> The remoteIpHeader setting is unnecessary. That is the default.
> The way I understand you, it shouldn't bother? I had added it because I
> was not sure about the capitalization.
Correct. The names of HTTP headers are not case-sensitive. Tomcat looks
them up in a case insensitive manner.
>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>> directory="logs"
>>> prefix="access_log." suffix=".log"
>>> pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
>>> "%r" %s %b"
>>> requestAttributesEnabled="true" />
>>
>> That isn't correct. You only need to add
>> requestAttributesEnabled="true"
>> to the default AccessLogValve. It will handle looking up the correct
>> attributes. You don't need to modify the pattern.
> I already worked with a modified log layout before the change. I only
> changed the %{org.apache.catalina.AccessLog.RemoteAddr}r. So would I
> have to replace %{org.apache.catalina.AccessLog.RemoteAddr}r with a %a?
I was using %h but %a should work just as well. Let me check ... yes it
does.
>> I also confirmed that the Valve order doesn't matter.
> So not like many on the Internet claim it matters?
Many on the internet are often wrong. Or at least the information they
present is incomplete, out of date and/or out of context.
In this specific instance, Valve order is irrelevant.
The general case is a request/response passes through the Valves (Engine
level Valves in order of definition, then Host Valves in order, then
Context Valves in order), gets processed by the application and then
returns through the valves in reverse order.
So, generally, order is important. However, there are some exceptions.
A Valve can choose not to pass the request/response on to the next stage
but to generate the response itself and return the request/response back
through the Valves it has passed through to that point.
The AccessLogValve is the other exception. It does not generate the log
entry at the point where the request/response passes through it. It used
to a long time ago but that changed with the fix for bug 50582 (in 2011).
It is important which Container (Engine, Host or Context) that the Valve
is added to since that will determine which request/response pairs get
logged.
>>> The request header 'X-Forwarded-For'
>>> was set and load balancer was analyzed via wireshark and Request
>>> Dumper
>>> Filter. We can see the header in both. However we still only get
>>> the IP
>>> of the load balancer and not the IP of the remote client. The IP
>>> adresses of the config have already been checked and they are
>>> correct.
>>
>> You can add "... %{X-Forwarded-For}i ..." to the pattern attribute of
>> the AccessLog valve to confirm that Tomcat sees this header value.
> In the beginning we tested it with Wireshark, later with a
> RequestDumper in the Tomcat. In both we saw the header.
>
>>
>> I've tested this locally with the latest 7.0.x and everything works
>> as
>> expected. I also don't recall any changes / bugs in this area
>> recently.
>>
>> A quick scan of the changelog does identify various improvements and
>> fixes since 7.0.76 but none that immediately jump out as likely to
>> cause
>> this simple configuration to fail.
> Thanks for looking into it.
I also built 7.0.76 and it worked there too. I explicitly set
internalProxies so my configuration was as close to yours as possible.
At this point it looks like configuration error. All I can suggest is
going back and re-checking everything. Personally, I'd start with a
clean 7.0.76 install, confirm the headers sent by the proxies and the IP
used by the proxies and then configure the RemoteIpValve.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
