chore(http-propagation): reduce complexity of traceparent parsing

[marcbachmann]

Which problem is this PR solving?

While writing a custom propagator for some job queue, I went trough the code and found that the traceparent extraction looked rather complex instead of just relying on a regex to simplify the logic. By merging all the regexes into one, we harden the functionality as less can go wrong.

Short description of the changes

I've rewritten the transparent header extraction to use one regex to be less susceptible for errors and attacks. e.g. when spoofing the header with traceparent: '-----------...' 8000 times or more (depending on header limit), it won't generate an array and allocate memory & block the event loop while parsing.

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Marc Bachmann (8386bb9)

[marcbachmann]

Does it make sense to have tests to extract future versions if we don't know the format? I'd rewrite that test to not extract the context.
edit: fix is coming. according to the spec a version should be forward-compatible: https://www.w3.org/TR/trace-context/#versioning-of-traceparent
edit2: and should be fixed. Weirdly is, I can't run the tests locally. I think it's currently broken because of the coming v1.

[codecov]

Codecov Report

Merging #1837 (867b42d) into master (31ab012) will decrease coverage by 0.38%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1837      +/-   ##
==========================================
- Coverage   92.66%   92.28%   -0.39%     
==========================================
  Files         174      165       -9     
  Lines        6040     5480     -560     
  Branches     1284     1172     -112     
==========================================
- Hits         5597     5057     -540     
+ Misses        443      423      -20     

Impacted Files	Coverage Δ
...y-core/src/context/propagation/HttpTraceContext.ts	100.00% <100.00%> (ø)
...-instrumentation-fetch/src/enums/AttributeNames.ts
...s/opentelemetry-instrumentation-fetch/src/fetch.ts
...kages/opentelemetry-web/src/StackContextManager.ts
packages/opentelemetry-web/src/utils.ts
...mentation-xml-http-request/src/enums/EventNames.ts
...ackages/opentelemetry-web/src/WebTracerProvider.ts
...ntelemetry-web/src/enums/PerformanceTimingNames.ts
...emetry-instrumentation-xml-http-request/src/xhr.ts
packages/opentelemetry-web/src/types.ts

[obecny]

what about performance, does it somehow impact that, hopefully it is not worst ?,

[marcbachmann]

what about performance, does it somehow impact that, hopefully it is not worst ?,

I did some benchmarks during the refactoring. Sadly I somehow discarded the benchmark script. Valid traceparent values were about 20% faster. Invalid ones 10 times faster.

If we care about performance even more, we could remove the \s at start and end, which are not needed as the http parser removes whitespaces before header values.

[dyladan]

Lint failure is no fault of this PR