Hello Mark,
I could test the change today, unfortunately only with moderate
success. The change to %a or %h, unfortunately did not work, but the
readout with the header value per %{X-Forwarded-For}i worked. The log
doesn't look nice, but we get the value. Nevertheless I am still
looking for a nicer solution. I was really hoping on %a that we would
only see the IP of the load balancer if no header is set, but still
always see an IP.
Do you have any more ideas what to watch?
PS:For a Tomcat update I have to ask other contacts if it is easy to
do.
--
Frank Tornack
Am Mittwoch, den 01.04.2020, 09:35 +0100 schrieb Mark Thomas:
> 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\.xx
> > > > x\.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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
