The OTLP/HTTP retry path currently uses the configured retry policy backoff, but it does not honor the Retry-After response header.

This is out of line with the OTLP/HTTP spec clarification in open-telemetry/opentelemetry-proto#806: Retry-After can be either an HTTP-date or a delay in seconds, and clients SHOULD honor the value when present.

I verified this against current main:

• exporters/otlp/src/otlp_http_client.cc passes options_.retry_policy to the HTTP request via request->SetRetryPolicy(...).
• ext/include/opentelemetry/ext/http/client/http_client.h models RetryPolicy as max attempts plus exponential backoff parameters.
• ext/src/http/client/curl/http_operation_curl.cc checks retryable status codes 429, 502, 503, and 504 under ENABLE_OTLP_RETRY_PREVIEW.
• HttpOperation::NextRetryTime() computes the next retry time from the retry policy using exponential backoff and jitter.
• The retry decision/timing path does not parse response headers, so neither Retry-After: <delay-seconds> nor Retry-After: <HTTP-date> affects the next retry time.

Expected behavior

When an OTLP/HTTP response is retryable and includes Retry-After, the exporter should honor the header value before retrying.

The parser should support both forms defined by RFC 7231 section 7.1.3:

• delay-seconds, for example Retry-After: 5
• HTTP-date, for example Retry-After: Wed, 21 Oct 2015 07:28:00 GMT

References

• Retry-After can be an HTTP-date opentelemetry-proto#806
• Retry-After can be an HTTP-date opentelemetry-proto#806 (comment)
• https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.3