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
policy.follow_redirects - per-upstream option controlling whether the gateway follows upstream redirects. Defaults
to false: a 3xx is now propagated to the client instead of being chased. Set it to true to restore the previous
behavior, keeping in mind that the redirect is followed with the upstream's own TLS configuration and that Go strips Authorization and Cookie on cross-host hops.
New client error codes UPSTREAM_CLIENT_ERROR and UPSTREAM_REDIRECT, distinguishing an upstreams answer to the
client from an upstream failure.
Changed
Upstream responses are now classified by status class rather than the single >= 500 check. 5xx and transport
failures remain gateway failures (502, upstream body dropped); 3xx and 4xx are treated as answers addressed to the
client.
Single-upstream flows propagate the upstream status verbatim - a 404, 401, or 302 from the upstream now reaches the
client as a 404, 401, or 302. Aggregating flows are unaffected: a status is only propagated when every failed upstream
agreed on it, otherwise the response stays 502.
allowed_statuses is now enforced as a contract in both directions: a status on the list is always a success (its
body flows into data), and a status outside a non-empty list is a policy violation returning 502 UPSTREAM_MALFORMED, even for statuses that would otherwise be propagated.
Client errors and redirects no longer count as circuit breaker failures - a burst of 404s can no longer take a healthy
upstream out of rotation.
Responses with statuses that cannot carry a body (204, 304) are no longer wrapped in the JSON envelope.
Upstream policy validation is skipped for transport-level failures, which previously produced misleading empty body not allowed and status 0 not in allowed list messages on timeouts.
Fixed
A single-upstream flow returned 200 with the upstream's error body when the upstream answered 404, 401, or any
other non-2xx status outside allowed_statuses. Clients received a success for a request that failed.
The circuit breaker reset itself with the very request it rejected: a denied call was recorded as a success, so an
open breaker closed after blocking a single request instead of staying open until reset_timeout.
Retries never fired for upstreams without an explicit method:. Retry eligibility was judged against the raw
configured method rather than the effective one, so the empty default was never considered idempotent.
Empty upstream bodies (204, or 200 with no content) were reported as UPSTREAM_MALFORMED during aggregation, turning
a successful fan-out into a 206 partial response.
Aggregation error responses now carry the retried status correctly; an aborted read no longer produces a
redirect-shaped errors entry for legitimately empty 3xx bodies.