Fix: http.client_ip vs multiple addresses #2282

[garthk]

I took the example from the MDN docs for X-Forwarded-For.

Resolves #2282

[MadVikingGod]

The current behavior is to take whatever is returned by the first value. You have changed it so that if we get a header that has multiple values we only take the first.
I've not used this field much, but do you have any examples of why we shouldn't be moving the opposite direction? By which I mean try and combine all of the header fields into one long string?

[pellared]

I just added one little change suggestion

[codecov]

Codecov Report

Merging #2284 (4f70f09) into main (e9db047) will decrease coverage by 0.0%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##            main   #2284     +/-   ##
=======================================
- Coverage   72.6%   72.6%   -0.1%     
=======================================
  Files        172     172             
  Lines      11918   11919      +1     
=======================================
  Hits        8661    8661             
  Misses      3023    3023             
- Partials     234     235      +1     

Impacted Files	Coverage Δ
semconv/v1.4.0/http.go	95.1% <100.0%> (+<0.1%)	⬆️
...s/otlp/otlptrace/internal/connection/connection.go	14.6% <0.0%> (-1.6%)	⬇️
exporters/jaeger/jaeger.go	94.3% <0.0%> (+0.8%)	⬆️

[garthk]

@MadVikingGod I don't believe combining all the header values into one long string meets the specification. The HTTP Server Semantic Conventions describe http.client_ip as containing:

The IP address of the original client behind all proxies, if known (e.g. from X-Forwarded-For).

If they intended the value to contain the IP addresses of the original client and all proxies, I trust they would have said so.

[garthk]

Wait up: I shouldn't have accepted the suggestion without checking I understood the semantics. As shown in this play.golang.org example with n=1 we'll end up with all the addresses, every time. This is by the design of strings.SplitN. From the docs:

SplitN slices s into substrings separated by sep and returns a slice of the substrings between those separators.

The count determines the number of substrings to return:
n > 0: at most n substrings; the last substring will be the unsplit remainder.

Instead we must call strings.SplitN with n=2.

[garthk]

The tests caught the regression 🎉

Rebased and fixed.

[pellared]

Wait up: I shouldn't have accepted the suggestion without checking I understood the semantics. As shown in this play.golang.org example with n=1 we'll end up with all the addresses, every time. This is by the design of strings.SplitN. From the docs:

SplitN slices s into substrings separated by sep and returns a slice of the substrings between those separators.
The count determines the number of substrings to return:
n > 0: at most n substrings; the last substring will be the unsplit remainder.

Instead we must call strings.SplitN with n=2.

Sorry, my bad. It is good that we have unit tests 😄