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