fix(api): apply baggage size and entry caps on extract

[tonghuaroot]

Fixes #2163.

Summary

OpenTelemetry::Baggage::Propagation::TextMapPropagator declares three private constants for the W3C Baggage spec limits (MAX_ENTRIES = 180, MAX_ENTRY_LENGTH = 4096, MAX_TOTAL_LENGTH = 8192). The private encode helper used on inject applies all three, and dedicated tests exist for each one. The extract path does not consult any of them, so the inject and extract directions enforce different rules.

This PR hoists the existing inject-side policy into extract so the two paths share the same rule, mirroring what opentelemetry-go, opentelemetry-dotnet, opentelemetry-cpp, and recent opentelemetry-java already do on their inbound side.

Changes

api/lib/opentelemetry/baggage/propagation/text_map_propagator.rb:

• extract returns the original context if the header byte size exceeds MAX_TOTAL_LENGTH.
• A new private decode_entries helper runs the loop:
  • break once MAX_ENTRIES entries have been decoded
  • next past any entry whose byte size exceeds MAX_ENTRY_LENGTH
• The loop body was factored into the helper to keep extract within the project's Metrics/CyclomaticComplexity and Metrics/PerceivedComplexity budgets.

api/test/opentelemetry/baggage/propagation/text_map_propagator_test.rb:

• A new describe 'limits mirroring #inject' block adds three tests that parallel the existing inject-side cap tests:
  • returns the same context object when the header exceeds the total length of 8192 bytes
  • enforces max of 180 entries on extract
  • skips entries whose size exceeds the max entry length of 4096 bytes

Verification

$ cd api
$ bundle exec rake test
203 runs, 888 assertions, 0 failures, 0 errors, 0 skips

$ bundle exec rubocop lib/opentelemetry/baggage/propagation/text_map_propagator.rb \
                     test/opentelemetry/baggage/propagation/text_map_propagator_test.rb
2 files inspected, no offenses detected

Notes

This change was originally submitted via the private advisory channel (GHSA-g4r4-95p7-vp43, now closed) and the project responded that it is not considered a security vulnerability but is worth fixing, and asked for a standard issue + PR. The framing here is consistency between inject and extract, not security.

The behavior change is conservative:

• A header within the spec limits is parsed exactly as before.
• A header exceeding MAX_TOTAL_LENGTH becomes a no-op (returns the original context, same as the existing nil / empty? short-circuit).
• An individual entry exceeding MAX_ENTRY_LENGTH is skipped while other entries continue to decode, matching what encode does on the inject side.
• Entries beyond MAX_ENTRIES stop being decoded, matching the existing inject-side behaviour.

[xuan-cao-swi]

LGTM.

Not related to this PR, but based on your cross-check (e.g. Cross-implementation consistency), it seems like otel spec doesn't restrict on single entry size anymore?

[mwear]

I looked at the baggage specification for limits and found the following:

Condition 1: The resulting baggage-string contains 64 list-members or less.
Condition 2: The resulting baggage-string is of size 8192 bytes or less.

I didn't find a per-entry limit. So we can remove that on both inject and extract. MAX_ENTRIES should be reduced to 64. I realize some of these issues are inherited. Do you want to address these as part of this PR?

[kaylareopelle]

Hi @tonghuaroot! Have you had a chance to review @mwear's comment?

I looked at the baggage specification for limits and found the following:

Condition 1: The resulting baggage-string contains 64 list-members or less. Condition 2: The resulting baggage-string is of size 8192 bytes or less.

I didn't find a per-entry limit. So we can remove that on both inject and extract. MAX_ENTRIES should be reduced to 64. I realize some of these issues are inherited. Do you want to address these as part of this PR?