error-page

error-page

Replaces the body and content-type of gateway-generated error responses with configured pages. It is a response-phase node — place it after upstream (typically also downstream of the error-handler node whose output it decorates), before client.

Only four status codes are supported: 404, 500, 502, 503.

Configuration

All keys are optional; only the configured statuses are intercepted. Each of error_404, error_500, error_502, error_503 is an object with:

Key	Type	Default	Description
body	string	a built-in HTML page for that status (<h1>502 Bad Gateway</h1> ... with a featherbit footer)	The replacement response body.
content_type	string	text/html	The replacement content-type header value.

Setting a key to an empty object {} selects the defaults for that status. A non-object error_XXX value, or a non-string body/content_type, fails at config load. error_XXX keys outside the supported set are ignored.

type: error-page
config:
  error_502:
    body: '{"error": "upstream unavailable"}'
    content_type: application/json
  error_503: {}   # default featherbit HTML page

Behavior

This plugin never fails at execution time — it always exits through the success port.

A response is rewritten only when both hold:

1. it was generated by the gateway itself — the heuristic is context.errors being non-empty: a response produced by the gateway (error-handler, auth rejection, upstream connection failure, ...) always carries the error record that routed it there, while a clean upstream response does not. An upstream's own 502 therefore passes through untouched;
2. its status code has a configured error_XXX page.

The rewrite sets the body and content-type, and removes content-length and content-encoding (the server layer recomputes the length; the configured page is not encoded). The status code itself is never changed.

Behavior notes: the pages live directly in the node config — there is no separate metadata tier or enable flag; placing the node in the graph is the enable switch. Whether a response is gateway-generated is decided by the context.errors heuristic described above.

The plugin reads context.errors but never writes it, and does not touch context.message.