cgalo5758
8e3c68c6be
- Add deployment-name branding to titles, mastheads, and OG tags - Share one grant delivery-state query with lineage across grants surfaces - Show pool status/usage, org owners, and config readiness - Make billing views projection-aware with recency and sync vocabulary - Guard FedWiki creation without domains and render route-aware 404s
2.9 KiB
error-pages Specification
Purpose
Render styled, chrome-wrapped error pages for navigation requests that resolve to 404 or 500, without leaking internals, while preserving the plain-text error contract for HTMX partials and degrading safely when the error template itself cannot render.
Requirements
Requirement: Navigation error responses render styled pages
The system SHALL render styled, full-page error responses inside the standard page chrome for navigation (non-HTMX) requests that resolve to 404 or 500. The page SHALL show the status and a short human-readable message, and SHALL NOT expose internal details (panic values, stack traces, file paths). The styled 404 SHALL render for unauthenticated visitors too: a request for a path no route matches SHALL receive the 404 page rather than a redirect into the identity provider's sign-in flow, so a mistyped or stale URL is diagnosed as "not found" instead of misread as "signed out". Routes that do exist but require authentication keep their normal redirect-to-login behavior.
Scenario: Unknown route renders a styled 404
- WHEN a browser issues a GET navigation request for a path no route matches
- THEN the response SHALL have status 404
- AND the body SHALL be the styled error page rendered inside the standard page chrome
Scenario: Anonymous visitor to an unknown route gets the 404, not a login form
- WHEN an unauthenticated browser requests a path no route matches
- THEN the response SHALL be the styled 404 page with status 404
- AND the visitor SHALL NOT be redirected to the identity provider's sign-in page
Scenario: Anonymous visitor to a real protected route still reaches login
- WHEN an unauthenticated browser requests a path that matches an authenticated route
- THEN the normal authentication redirect applies
Scenario: Panic renders a styled 500 without leaking internals
- WHEN a handler panics while serving a navigation request
- THEN the recovery middleware SHALL respond with status 500 and the styled error page
- AND the response body SHALL NOT contain the panic value or a stack trace
Requirement: Error rendering degrades safely
Error-page rendering SHALL preserve the existing plain-text error contract for HTMX partial requests, and SHALL fall back to a plain-text error when the error template itself cannot render.
Scenario: HTMX partial requests keep text errors
- WHEN a request carrying
HX-Request: trueresolves to an error status - THEN the response SHALL be the existing plain-text error consumed by the client-side error toast, not a full HTML page
Scenario: Template failure falls back to plain text
- WHEN rendering the error template itself fails
- THEN the system SHALL respond with a plain-text error carrying the same status
- AND SHALL NOT panic or emit a partially rendered page