Non-Standard Error Messages

What information do you need right now? Click on the links.

This article describes “non-standard” error messages numbered 429 or 503. The 503 code has several standard message bodies discussed in Proxy Server Error Response Messages. Here, we’ll discuss non-standard 503 messages, which generally come from a remote site rather than the proxy. The 429 code also comes from destination servers, and has no standard message body.

Both message types, 429 and 503, may be accompanied by a Retry-After message, specifying how long you should wait before retrying the request at that site.

Working with a 429 message

Generally, a 429 error signals a potential request overload for the remote site or a rate limit for the sender of a request. An overload can occur if you exceed the site’s rate limit, that is, the number of requests the site will accept from you in a given period. If the remote site has a shared server, too many requests from one source would affect service to the other users. Typically, the 429 error is intended to prevent such a situation.

Sample messages

This numeric code has no standard message bodies, but here’s a few you might encounter:

From Chrome browser: “This site can’t be reached…”

From Google: “That’s an error. We’re sorry, but you have sent too many requests to us recently. Please try again later. That’s all we know.”

From Safari browser: “429 Too Many Requests. You have sent too many requests in a given time”

Recommended in RFC 6585

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

“RFC” is Request for Comments published by the Internet Engineering Task Force.

How to resolve

Here are some tips for following up on a 429 message.

Wait to send another request. You might wait a few seconds or a few minutes. If the message specifies a wait time, like the RFC example above, follow that guideline.

Send retries at increasing intervals. Not all 429 messages specify a retry wait period. Try sending several retries with increasing intervals between attempts. Note the last interval before the request is accepted and you’ll have the wait time for that site. You can perform these retries manually, but Celery, an open-source job queue for Python users (and usable in other languages too), includes a feature called “exponential backoff” which automates serial retries.

Set a rate limit in your scripts. If you send requests via script or API, you can configure a limit on the number you send per time period to a specific site. You can optionally set a lower limit than that of a remote site. That way, you can avoid warnings or actual bans from the site.

Working with a 503 error

The non-standard 503 (service unavailable) message can be hard to interpret and resolve. That’s because it may provide little additional information beyond this message. Also, not all servers send this message; some may simply refuse a connection when they have a problem. If a remote site does send this message with a Retry-After, the header can help you identify the origin of the issue.

Several repetitions of the 503 error in a short period can cause a temporary ban on your requests. You can usually make a successful connection if you wait out the ban and try again. In other cases, the issue may be with the remote site and not with your requests. For example, the remote server may be overloaded or may be down for maintenance; or the connection between the remote site and its server may be interrupted.

“Retry-After”

As in the RFC example above, a Retry-After header indicates how long you or your user agent should wait before resubmitting a data request. This header can be included in 503 (service unavailable) messages and 429 messages, though the latter do not always incorporate it.

If Retry-After specifies a date, it can mean that the server is down for repairs or upgrade and you can resend your request after that date. This is the usual purpose of sending a retry with 503 (service unavailable).

Retry-After specifying seconds or minutes means a suggested wait period before making a new request. Some but not all remote websites send this type of Retry-After along with a 429 code.