Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backend react to 429 status - Too Many Requests #754

Open
malud opened this issue Apr 6, 2023 · 0 comments
Open

Backend react to 429 status - Too Many Requests #754

malud opened this issue Apr 6, 2023 · 0 comments
Labels

Comments

@malud
Copy link
Collaborator

malud commented Apr 6, 2023

Couper should react to 429 status-code responses and will retry this particular request with the given delay from the response header Retry-After (in seconds). Maybe there is just the status-code without Retry-After header then we fallback to a configurable (default)value. In an ideal world the related backend would block/hold all other outgoing requests after seeing the first 429 but this will have no priority for the first implementation and could be somehow bypassed while reducing the max_connections.

We have to consider to buffer the request.body for a possible retry. While seeing the backend.retries block(or attribute) at startup, we have the option to enable this particular BufferOption.

So to not break our existing behaviour this would be an opt-in option and will give us the knowledge that we have to buffer all client bodies for this particular route.

Real world examples:

possible configuration:

backend {
  retries = true #opt-in
  # or for refinement options
  retries { # opt-in
    fallback_retry_after = 20s # fallback for a missing `Retry-After` header value; default: 10s
    status_codes = [429, 503] # default 429
    attempts = 2 # default: 5; must be greater zero
  }
}
@malud malud added the proposal label Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant