0.29.7

docs/CUSTOM_LOCATIONS.md

@@ -116,6 +116,17 @@ RustProxy 0.29.1 can mark a Custom location as `internal`. An internal location
 
 This is an internal request handoff, not an HTTP redirect. The original method, URI/query and request context are retained. The fallback target re-enters normal access/header/cache/compression/response processing. Fallback targets must be enabled internal locations in the same vhost; validation rejects cycles and runtime dispatch is depth-limited. See [0.29.1 implementation note](V0.29.1_IMPLEMENTATION.md).
 
+### Replace origin error bodies without an internal location (0.29.7)
+
+The independent, optional **Vhost → Pages → Intercept application error responses**
+setting (`pages.intercept_statuses`, for example `[404, 503]`) replaces a
+backend or Web Server/PHP origin's error *body* with the configured vhost
+error page, then global error page, or a built-in page. It retains the HTTP
+status and sets `Cache-Control: no-store`. Unlike `error_fallback`, it does
+**not** forward the request to a different backend. The existing internal
+`error_fallback` action has priority and its final response remains intact.
+See [Web Server – application HTTP error interception](WEB_SERVER.md#intercept-application-http-errors-0297).
+
 ## What is intentionally not an Nginx parser
 
 Custom locations do **not** execute arbitrary Nginx directives or configuration snippets. RustProxy does not currently implement location-level `try_files`, per-location filesystem aliases/roots, embedded scripting, arbitrary `if` expressions or arbitrary module directives. Static roots are defined only by reusable Web Services. Use the explicit UI controls and the documented JSON schema instead; unknown fields are rejected on save.