Error pages for 404 and other status codes
There are situations when a page can't be found in a site, and situations when an application returns a status code indicating such a condition, or a similar one. ShimmerCat QS allows for handling these situations in different ways.
Error pages for electric domains
In an electric domain running
when the application backend returns a 404 code ShimmerCat
relays that 404 response from the aplication backend to the client.
internet mode, ShimmerCat tries to find a
which is looked up exactly as
__index.html files would in the views
The rationale is that 404 and other error situations should consume resources from ShimmerCat and be served with cacheable and cached assets, and not from the backend itself since the later is often more expensive.
The same applies to 50x error pages, where the small
x represents an actual digit for
an HTTP error status code.
The rationale here is to avoid leaks of sensitive information that may be present in
500-error application diagnostics from production servers, and to avoid forwarding
additional traffic to a backend which is returning error codes due to overload.
In all cases, if there is no custom
__50x.html file, ShimmerCat supplies
an internal one.
Forwarding the error pages from the backends
Of course, there are situations when it's desirable to instead return the error pages
from the backend.
This can be done via a stacked setting
set in either a particular view or for the entire backend.
<!-- shimmercat: content-disposition: replace forward-error-pages: true -->
The setting takes a boolean value, with
true meaning "send whatever the backend sends back to the browser".
Even with this setting on, there are cases however where the pages configured are used:
- If there is no view in ShimmerCat QS that would otherwise handle the request, then the request is not
sent to any backend, and a default
__404.htmlis looked up.
- If ShimmerCat QS can't connect to the application backend, then a configured
__503.htmlfile or an internal page is used.
Error pages for API domains
For API domains, whatever the consultant returns is always forwarded to the HTTP client.