Undo field migration of nginx.access.remote_ip_list.

[webmat]

This field contains the array of forwarded IPs, and should not have been mapped to network.forwarded_ip, which is meant to contain the "real" IP.

Caveats

• Note that the PR doesn't actually populate network.forwarded_ip with the single restored IP right now. It populates source.ip directly instead. Open to discussion.

The change reverted here was done in #9081, which went into 7.0.0-alpha2.

[webmat]

Test failure in Jenkins is unrelated (libbeat)

[ruflin]

Not sure I can follow here. You describe the field as forwarded ips but they should not go into network.forward_ip?

[webmat]

Yeah, I could have been more clear LOL.

When reviewing @andrewkroh's #9976, it occurred to me that people typically refer to the real source ip as forwarded_ip, because it comes from the xff header.

In my initial NGINX migration, I had moved the whole array in X-Forwarded-For header to network.forwarded_ip. The ECS field description is pretty clear that this should be the "real" restored IP, no the whole array.

Wanting to match Packetbeat's semantics, the common parlance and the ECS definition, I decided to keep the array around anyway, as the old field name, and no longer putting the array in network.forwarded_ip. And actually I'm not populating network.forwarded_ip as defined in ECS, because this value is already present in source.ip.

So I don't know, I think ECS could support the array, but this may require some discussion. Should we add one field, or consider the whole space of proxies? Aka, a discussion better left for next week :-)

[ruflin]

ECS supports an array by default for every field. I think in the end it comes down to on which fields users are querying on.

Approving this PR as agree, we can discuss this in more detail later.

PS: Needs a rebase.