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.
Couper should react to
429
status-code responses and will retry this particular request with the given delay from the response headerRetry-After
(in seconds). Maybe there is just the status-code withoutRetry-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 first429
but this will have no priority for the first implementation and could be somehow bypassed while reducing themax_connections
.We have to consider to buffer the
request.body
for a possible retry. While seeing thebackend.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: