Which HTTP errors should never trigger an automatic retry?

http microservices httpresponse hystrix spring-retry
cahen picture cahen · Dec 6, 2017 · Viewed 9.3k times · Source

I'm trying to make a few microservices more resilient and retrying certain types of HTTP requests would help with that.

Retrying timeouts will give clients a terribly slow experience, so I don't intend to retry in this case. Retrying 400s doesn't help because a bad request will remain a bad request a few milliseconds later.

I imagine there are other reasons to not retry a few other types of errors, but which errors and why?

Answer

Constantin Galbenu picture Constantin Galbenu · Dec 16, 2017

There are some errors that should not be retried because they seem permanent:

  • 400 Bad Request
  • 401 Unauthorized
  • 402 Payment Required
  • 403 Forbidden
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 407 Proxy Authentication Required
  • 409 Conflict - it depends
  • 410 Gone
  • 411 Length Required
  • 412 Precondition Failed
  • 413 Payload Too Large 
  • 414 URI Too Long
  • 415 Unsupported Media Type
  • 416 Range Not Satisfiable
  • 417 Expectation Failed
  • 418 I'm a teapot - not sure about this one
  • 421 Misdirected Request
  • 422 Unprocessable Entity
  • 423 Locked - it depends on how long a resource is locked in average (?)
  • 424 Failed Dependency
  • 426 Upgrade Required - can the client be upgraded automatically?
  • 428 Precondition Required - I don't thing that the precondition can be fulfiled the second time without retring from the beginning of the whole process but it depends
  • 429 Too Many Requests - it depends but it should not be retried to fast
  • 431 Request Header Fields TooLarge
  • 451 Unavailable For Legal Reasons

So, most of the 4** Client errors should not be retried.

The 5** Servers errors that should not be retried:

  • 500 Internal Server Error
  • 501 Not Implemented
  • 502 Bad Gateway - I saw used for temporary errors so it depends
  • 505 HTTP Version Not Supported
  • 506 Variant Also Negotiates
  • 507 Insufficient Storage
  • 508 Loop Detected
  • 510 Not Extended
  • 511 Network Authentication Required

However, in order to make the microservices more resilient you should use the Circuit breaker pattern and fail fast when the upstream is down.

Related questions

Orchestrating microservices

What is the standard pattern of orchestrating microservices? If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what's the way to go about it? …

Read More
PUT vs. POST in REST

According to the HTTP/1.1 Spec: The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line In other words, …

Read More
How are parameters sent in an HTTP POST request?

In an HTTP GET request, parameters are sent as a query string: http://example.com/page?parameter=value&also;=another In an HTTP POST request, the parameters are not sent along with the URI. Where are the values? In …

Read More