You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Especially if the proxy block is within wildcard endpoint block
endpoint"/**" {
proxy {
backend="api_backend"
}
}
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.
The text was updated successfully, but these errors were encountered:
Implement a new attribute for the
proxy
block:unexpected_status
.Use case: see discussion #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.The text was updated successfully, but these errors were encountered: