Custom Pages

Custom Pages is a functionality that allows you to customize error pages for users based on the status code received from the edge connectors.

View as Markdown

Important — We’re releasing a significant update to our platform. To learn more about the changes and required migration steps, see the API v4 rollout page.

This page documents the new Custom Pages product. If your account hasn’t been migrated yet, refer to the legacy Error Responses documentation.

Custom Pages is an Azion feature that allows you to customize error pages for users based on the status code received from an Connector.

When a user requests content from an application, Azion sends the request to the origin servers using Connector. As a response, the Connector sends back an HTTP status code, which indicates whether or not the request has been completed.

See the specifications on HTTP status codes for more information on HTTP statuses.

With Custom Pages, you can customize how your application will handle Client (4xx) and Server (5xx) error types. This way, when a request is made to a URL that can’t be found at the origin or when the server is unable to respond, the user will be redirected to a custom error page, whose contents can be cached.

Implementation

Scope	Resource
Application first steps	First steps
Customizing error page	How to customize an error response page
Connectors	Connectors reference
Workloads	Workloads reference
Custom Pages API	API reference

Page Codes

The code Azion receives from the Connector when connecting to the origin.

These are the available status codes:

Status Code	Description
400: Bad Request	Request error caused by invalid parameters, missing required parameters, or others.
401: Unauthorized	Error resulting from a lack of the `Authentication` HTTP header.
403: Forbidden	Lack of user permissions to execute the operation.
404: Not Found	The resource requested doesn’t exist.
405: Method Not Allowed	The requested method can’t be applied to the URL.
406: Not Acceptable	`Accept` header wasn’t found in the HTTP request or header contains content whose formatting or version isn’t supported by the API.
408: Request Timeout	The server informs that the request is coming in slower than the server is prepared to wait. This means the server would like to terminate the connection. This response is often used since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection to speed up navigation. Also, some servers take down the connection without sending this message.
409: Conflict	Conflict in the execution of the request, such as creating an existing registry.
410: Gone	This response is sent when the requested content was permanently deleted from the server, without a preset redirect address. If this error happens, any caches or links to this resource should be removed. The HTTP specification describes that this code should be used for “limited promotional services”. APIs shouldn’t be made to indicate which resources were removed with this status code.
411: Length Required	The server has rejected the request because the header `Content-Length` is undefined but required by the server.
414: URI Too Long	The requested URI is larger than the server’s limits.
415: Unsupported Media Type	The media format of the requested data is unsupported by the server, so the server rejects it.
416: Request Range Not Satisfiable	The value specified by the `Range` header couldn’t be filled; it’s likely that it’s out of range of the target URI data.
426: Upgrade Required	The server refuses to execute the requisition using the current protocol, but it’ll be ready to do so after the client updates to a different protocol. The server sends an `Upgrade` header response to indicate the required protocols.
429: Too Many Requests	The request was temporarily rejected for exceeding operation limits. The client must wait until the moment defined in the `X-Ratelimit-Reset` and try again.
431: Request Header Fields Too Large	The request’s headers are too long or too many cookies were sent in the request.
500: Internal Server Error	Unintentional error, fault unidentified in the processing of the request.
501: Not Implemented	The request method is unsupported by the server and can’t be modified. The only methods required for servers to support (and thus shouldn’t return this code) are GET and HEAD.
502: Bad Gateway	This error response means that the server, working as a gateway in order to obtain a necessary response to manipulate the request, obtained an invalid response.
503: Service Unavailable	The server isn’t ready to handle the request. Common causes are an overloaded server or a server under maintenance. Next to this response, a friendly page explaining the problem should be sent. These responses should be used for temporary conditions and the `Retry-After` header should contain the estimated time to recover the service. The webmaster should also be careful with the caching related headers that are sent with this response, since these temporary condition responses shouldn’t normally be cached.
504: Gateway Timeout	This error response is sent when the server is acting as a gateway and doesn’t obtain a response in time.
505: HTTP Version Not Supported	The HTTP version used in the request isn’t supported by the server.

Response TTL

Defines the time in seconds that the error page will remain in cache before it’s refreshed.

Learn more about cache expiration settings

Page Path (URI)

This path specifies the internal URL from which your Connector delivers the payload. For example, if you set the path to /myerrors/505.html and your Connector address is myconnector.azion.com, the content will be fetched and delivered from myconnector.azion.com/myerrors/505.html.

Response Custom Status Code

Status code that will be delivered to the user instead of the original one. For example, you can configure the application to return a 404 response code when a 403 error occurs.