[Feature Request] Make X-Request-Id validation configurable

[tmanninger]

Is your feature request related to a problem? Please describe

Hi OpenSearch Team,

I’m looking at PR #19798 where X-Request-Id is currently validated as hex-only and exactly 32 chars.

• Many gateways / load balancers emit request IDs that are not hex-only.
• Operators often want to pass through an existing correlation ID end-to-end without rewriting.

Before I start implementing anything, I’d like to ask if you would be OK with me opening a PR that removes the hex-only restriction and makes only the length configurable, while keeping the current behavior as the default.

Describe the solution you'd like

• Introduce a setting like http.request_id.max_length (default: 32).

• Validation would enforce:

  • header is present / non-empty (as today)
  • length is <= max_length (default keeps 32)

• The hex character check would be removed, so operators can propagate common request-id formats (UUID/ULID/base64url-like tokens, vendor-specific IDs) unchanged.

Related component

Search

Describe alternatives you've considered

No response

Additional context

No response

[Illuminati9]

Hi @reta , Can I work on this?

[reta]

Hi @reta , Can I work on this?

Absolutely, thank you @Illuminati9

[mymasse]

Is this going to get fixed soon, this is preventing us from upgrading to 3.5. We deploy opensearch in kubernetes fronted by the Nginx Ingress Controller which adds automatically the X-Request-Id header but as a UUID with dashes which fails the validation.

As a separate change is using a different header a possibility, reading the comments on the initial PR feels like this is mainly for internal use however as mentioned above X-Request-Id is already commonly used by Gateways and Load-balancers, using a different more unique header would resolve the issue: for example X-Opensearch-Request-Id

[Illuminati9]

I'm currently working on it and it may take 1 or 2 days. If it is blocking your release, you may proceed with alternate approach.

[mymasse]

Will changing the validation even work, I inserted a proxy in front of one of our opensearch cluster and replaced the X-Request-Id UUID with one without the dashes to make it pass the current validation and now I'm getting: type=illegal_argument_exception, reason=value for key [X-Request-Id] already present]

[sgup432]

@mymasse You are likely getting hit by opensearch-project/security#5951 and you need to consume the latest security plugin fix to avoid this issue.

@Illuminati9 Let me also know once you have the PR ready

[inflatador]

@Illuminati9 Thanks for taking a look at this. At Wikimedia Foundation we are trying to work around this by using a TLS proxy in front of OpenSearch, but that makes it difficult to monitor the pod certificates.

Let us know if you need help! I'm not sure how much time our software developers have, but we can certainly take a look if you're stuck.