Skip to content

0.9.0

Latest

Choose a tag to compare

@starwalkn starwalkn released this 09 Aug 16:11

Added

  • 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.