Request Routing Rules

To use the EdjPlatform server to manage CDN traffic, you must define request routing rules as appropriate for your data. Rules tell the EdjPlatform what action to perform and when.

Make sure you have the required permissions to add or modify resources in the EdjPlatform, which are based on group permissions assigned to each user group. See Groups for details.

The EdjPlatform supports the following routing actions:

  • Redirect Rule — Client-side request. The EdjPlatform sends a 302 temporary redirect response with the location header in the response.

  • Rewrite Rule — Server-side request. The EdjPlatform makes the changes so that the user accessing the site does not see the changes. Use this action to rewrite a URL to the same website with a relative path. When rewriting to a different website, the EdjPlatform serves as the reverse proxy. Some other reasons for this action type:

    • One or more <path> or <query_string> segment is rewritten.
      The EDJX Server will rewrite the URI parameter of the HTTP request.

    • One or more <hostname>, <:port>, or <scheme> segment is rewritten.
      The EDJX Server acts as a proxy to the target server.

      NOTE

      Add the <scheme> segment to the routing destination.+ Make sure your target server supports TLS verification for the requesting domain.

Routing Destinations

A routing destination is presented with the following segments:

<scheme>://<hostname>/<path>?<query_string>

Where,

  • <scheme> - Used for the same scheme of incoming requests for the routing target destination.

  • <hostname> - Used as the host value of the incoming request.

  • <:port> - Optional. Used to capture values (including :) of the incoming request port number.
    By default, for HTTP and HTTPS requests (port 80 and 443, respectively) leave this placeholder blank.

  • <path> - Used to capture the incoming request’s path value (including \).
    NOTE: Add a backslash (\) before the placeholder if you are using \<path> without a prefix; otherwise, parsing issues could occur for the provided value.

  • <query_string> - Used to capture the incoming request’s raw query value (without ?).

Match Values

The match values set the condition in which to perform a defined action.

When setting Match Values for Exact Matches, the <path> and <query_string> segments use strict matching even if not specified. Match values for this match type, route requests from user-specific URL paths.

If the <path> segment is not specified, the system uses an empty string or a backslash \ in its place.
If the <query_string> segment is not specified, the system will match for empty segments in the incoming request.

Examples of a MATCH VALUE for an Exact Match are as follows:

http://example.com/support?name=acme
https://example.com/support?name=acme

When setting Match Values for Pattern Matches, the <scheme> and <:port> segments will be matched exactly in the HTTP request.
The <hostname> segment will be matched against the wildcard <hostname> segment.

No strict matching will be applied if the <path> and <query_string> segments are not specified.

Routing Match Types

Routing match types work as follows:

  • Exact Match - Matches each segment within the MATCH VALUE text field. That is, the <scheme>, <hostname>, and <:port> of the HTTP request will be matched exactly when specified in the MATCH VALUE text field.

  • Pattern Match - Matches wildcards (*) for <hostname> and <path> request segments.
    For example: https://*.example.com or www.example.com/cdn/*

Using Wildcards

Wildcard (*) can be used for <hostname> and <path> segments as follows:

  • <hostname> - Used to represent exactly one label of the <hostname>.

Wildcards are useful when matching all subdomains is required.

For example,

*.example.com matches foo.example.com but not foo.bar.example.com

  • <path> - Used to match requests by the URI’s path (case-insensitive). It can contain the following options:

    • For a prefix match (/prefix/*)

    • For a suffix match (*.suffix)

    • For a substring match (*/contains/*)

    • For a globular match (/accounts/*/info)

Example Rules

Rewriting a Hostname Segment

The following example indicates that a URL request with a given <hostname> segment be rewritten with a static <hostname> and <port> segments.

match-type: Pattern Match
match-value: http://www.example.com
proxy action: rewrite
route action: http://images.example.com:8085

Removing the Query Segment Values

The following example indicates that a URL request with a specific <query_string> segment be removed and rewritten on the server-side.

match-type: Exact Match
match-value: http://example.com/support?name=acme
proxy action: rewrite
route action: http://<hostname>/<path>

Rewriting a Query Segment Value

The following example indicates that a URL request with a specific <query_string> segment be rewritten on the server-side.

match-type: Exact Match
match-value: https://example.com/support?name=acme
proxy action: rewrite
route action: https://<hostname>/<path>?name=google

Rewriting a Path Value

The following example indicates that a URL request with a specific <path> segment be rewritten with the addition of the <query_string> segment on the server-side.

match-type: Pattern Match
match-value: http://example.com/support
proxy action: rewrite
route action: http://<hostname>/<path>?name=google

Rewriting a Wildcard Path Segment to a Static Path Segment

The following example indicates that a URL request wildcard as the <path> segment be rewritten with a static <path> segment value "tickets" on the server-side.

match-type: Pattern Match
match-value: https://example.com/support/*?name=acme
proxy action: rewrite
route action: https://<hostname>/tickets?<query_string>

Rewriting the Port and Path Segments of a Request URL

The following example indicates that a URL request for specific <path> segments be rewritten with a <:port> segment of 8080 and a static <path> segment or a <:port> segment of 8080, a static <path>, and a specific <query_string> segment on the serve-side.

match-type: Pattern Match
match-value: http://example.com/*?name=acme or http://example.com/support?name=acme or http://example.com/accounts?name=acme
proxy action: rewrite
route action: http://<hostname>:8080/customer?<query_string> or http://example.com:8080/customer?name=acme