Real IP detection is not working properly when KeepAlive is in effect

[GertSallaerts]

Expected Behavior

When the recent features for detecting the real IP (through x-forwarded-for and various other options) are enabled on a GELF HTTP input, two request that reuse the same connection to the input but have different values in the forwarded headers, should also show those two different values on the resulting logs in Graylog.

Current Behavior

What happens now, is that the real IP of the first log message is reused for the second log.

Possible Solution

I suspect (though I'm not very familiar with the project's internals nor Java itself) that on the line I linked below, the Real IP gets stored in the context of the channel and that a request that reuses the same connection (because KeepAlive is active) also uses the same channel? And that the setIfAbsent as a result won't set the new IP for subsequent requests on the same connection.

graylog2-server/graylog2-server/src/main/java/org/graylog2/inputs/transports/netty/HttpForwardedForHandler.java

Line 156 in d91023c

ctx.channel().attr(RawMessageHandler.ORIGINAL_IP_KEY).setIfAbsent(new InetSocketAddress(inetAddress, 0));

Steps to Reproduce (for bugs)

1. Set up a Gelf HTTP input
2. Configure it to pull the real IP from a random header (e.g. x-foo-bar)

Config should look like this:

enable_forwarded_for: false
enable_real_ip_header: true
real_ip_header_name: x-foo-bar
require_trusted_proxies: false

At that point, if you post two logs using cURL like this:

curl -v --http1.1 \
  http://localhost:12201/gelf \
  -H 'content-type: text/plain' \
  -H 'x-foo-bar: 1.1.1.1' \
  --data '{"version":"1.1","short_message":"test","full_message":"test"}' \
  --next \
  http://localhost:12201/gelf \
  -H 'content-type: text/plain' \
  -H 'x-foo-bar: 2.2.2.2' \
  --data '{"version":"1.1","short_message":"test","full_message":"test"}'

The resulting logs both show the first (1.1.1.1) IP as the source instead of showing two different ones.

Context

The example seems a bit silly, but that's just the easiest way to reproduce. We noticed this because in our case, Graylog is behing an AWS Application Load Balancer that keeps connections to the upstream target alive. And there does not seem to be any way to turn this off.

Your Environment

Graylog 7.0.2+7a367fe on d8f7c007b201 (Eclipse Adoptium 21.0.9 on Linux 6.1.156-177.286.amzn2023.x86_64)

Checklist

[] This issue fix need to be backported.
[] Does this issue have security implications?