all sorts of valid status codes can occur due to the endpoint proxying to potentially a lot of backend API endpoints.
So if you want to react to a specific error status code, e.g. 401, with an error_handler "unexpected_status" and proxy all other responses, you cannot use the expected_status attribute. Here, an unexpected_status attribute would come in handy:
endpoint "/**" {
proxy {
backend = "api_backend"
unexpected_status = [401]
}
error_handler "unexpected_status" {
# try to get a fresh token
}
}
Should the new attribute be mutually exclusive with expected_status?
I don't think that the other block types that have expected_status (request, beta_token_request, health) would profit from an unexpected_status attribute. All three are usually used for specific requests, where only a very limited set of status codes are treated as valid.
Implement a new attribute for the
proxy
block:unexpected_status
.Use case: see discussion https://github.com/coupergateway/couper/discussions/723.
Especially if the
proxy
block is within wildcardendpoint
blockall sorts of valid status codes can occur due to the endpoint proxying to potentially a lot of backend API endpoints.
So if you want to react to a specific error status code, e.g. 401, with an
error_handler "unexpected_status"
and proxy all other responses, you cannot use theexpected_status
attribute. Here, anunexpected_status
attribute would come in handy:Should the new attribute be mutually exclusive with
expected_status
?I don't think that the other block types that have
expected_status
(request
,beta_token_request
,health
) would profit from anunexpected_status
attribute. All three are usually used for specific requests, where only a very limited set of status codes are treated as valid.