Fix IPv6 parsing errors in semconv.NetAttributesFromHTTPRequest

[evantorrie]

fixes #2283

[codecov]

Codecov Report

Merging #2285 (69b88ab) into main (43465e8) will increase coverage by 0.0%.
The diff coverage is 100.0%.

@@          Coverage Diff          @@
##            main   #2285   +/-   ##
=====================================
  Coverage   72.6%   72.6%           
=====================================
  Files        172     172           
  Lines      11919   11898   -21     
=====================================
- Hits        8661    8646   -15     
+ Misses      3023    3019    -4     
+ Partials     235     233    -2     

Impacted Files	Coverage Δ
semconv/v1.4.0/http.go	96.3% <100.0%> (+1.2%)	⬆️
...s/otlp/otlptrace/internal/connection/connection.go	16.2% <0.0%> (+1.5%)	⬆️

[garthk]

I don't recall touching any code relevant to TestNew_collectorConnectionDiesThenReconnects. Is that test flakey, by any chance, or do I need to dig deeper? Oh, sorry, wrong bug; I thought this was #2284. Thanks for picking this one up

[garthk]

I was expecting the implementation to shrink given net.SplitHostPort. Can we use it in the first line or two and take the fallback measures only if required—perhaps not at all? Under what circumstances would Go populate RemoteAddr without a port?

[pellared]

👍

[evantorrie]

@garthk I took your advice and refactored the code to assume the happy path succeeds, i.e. has a combination of both host and port. I do use the same routine to extract the hostIP/hostName and port for both request.RemoteAddr and the various permutations of request.Host, Host header and request URL. That means it needs to be a bit more robust than just assuming the Go runtime has set these reasonably (especially with things like parsing the Host header which comes direct from the "untrusted" client).

In any case, it looks like all the new IPv6 tests are passing and there are 20 fewer lines of code in http.go after this PR.