Per-Site error pages (replacing Jetty defaults)

[hugithordarson]

Context

When something goes wrong in the frontend chain — proxy can't reach upstream, no app found for hostname, 404, etc. — modulo currently returns Jetty's default error page. It's an ISO-8859-1-encoded HTML page that exposes a stack-trace-ish path and identifies the server software. For example, a misrouted request currently renders:

HTTP ERROR 500
java.lang.IllegalArgumentException: No application found with the name LocalApp/

Three problems:

1. Looks unprofessional for any real deployment.
2. Leaks implementation details (exception class names, internal paths).
3. No consistency with the look-and-feel of the actual sites being proxied — a 503 should look like it came from the same place as the real site, not from a debug tool.

What we need

• A clean default 4xx/5xx page that doesn't expose internals.
• A way for an operator to customize per-Site error pages — point at an HTML template (or a directory) per error class (4xx, 5xx) or per-status (404, 502, 503).
• Sensible defaults: terse, neutral styling, links back to the homepage.
• Don't log the same error twice (the proxy handler already logs the underlying failure; the error page handler shouldn't re-log).

Distinct error scenarios to think about

• Hostname not configured (unknown SNI / no Site).
• Site configured but no app routing match (current 500).
• App routing matched but upstream unreachable (502 / 504).
• Upstream returned 5xx (pass through? wrap? configurable?).
• Maintenance mode (operator-driven 503).

Open questions

• Per-Site override granularity: per-status, per-class, or just one catch-all template?
• Template language: static HTML with $token substitution, or something richer?
• Should the page be served compressed? (the gzip handler skips error responses by default — we should override that for HTML error pages)

Related

• Parent issue: Modulo as front-facing server: Site abstraction, native TLS, native logging #2 (Site abstraction)
• Iteration 1: Iteration 1: TLS termination via Apache-config import (drop-in Apache replacement) #3
• Existing code: modulo.ModuloProxy.ModuloErrorHandler — a small, half-finished stub that's a natural starting point.