# http.retry-after

How long to wait before trying again, from a `Retry-After` header on a 429
(Too Many Requests) or 503 response:

```
retryAfterSeconds("120", now)                             # 120
retryAfterSeconds("Wed, 21 Oct 2015 07:28:00 GMT", 1445412420)  # 60
retryAfterSeconds(null, now)                              # null: no header
retryAfterSeconds("soon", now)                            # null: not a Retry-After
```

RFC 9110 section 10.2.3 allows two forms:

- **delay-seconds**: one or more ASCII digits (`120`, `0`, `007`). Signs,
  fractions, other scripts' digits and more than nine digits (31 years) are
  not a wait anyone meant, so they are null.
- **HTTP-date**, in the preferred IMF-fixdate form
  (`Sun, 06 Nov 1994 08:49:37 GMT`, section 5.6.7): exactly that layout, day
  and month names in English with that capitalisation, `GMT` in capitals, a
  real calendar date (29 February only in a leap year, via
  `dates.is-leap-year`), hours 00-23 and seconds 00-59. It is turned into
  seconds from `now` through `time.iso-to-unix`; a date already past is 0.
  The day name is not checked against the date. The obsolete RFC 850 and
  asctime forms, which a recipient "SHOULD" accept, are refused here: nothing
  still sends them, and each is a two-digit-year or zone ambiguity.

Spaces and tabs around the value are ignored (HTTP's optional whitespace);
anything else, a newline included, is null. Null is a signal, not an error:
the caller falls back to its own backoff rather than trusting a garbled
header. The caller reads the clock and passes `now` in whole Unix seconds;
a fraction throws "now must be a whole number of seconds".

Pair it with `time.countdown(now + seconds, now)` to show the wait ticking
down.

Source: RFC 9110, HTTP Semantics, sections 10.2.3 (Retry-After) and 5.6.7
(Date/Time Formats), https://www.rfc-editor.org/rfc/rfc9110.