This section provides match rule examples.
API Prioritization
API Prioritization allows you to specify, for applications that call resources of various formats (like JSON or XML), which calls are given priority and are sent to the origin during high-demand situations. Based on information in the inbound request, you configure the rules that determine which calls are prioritized.
Match rule example
For this example, if the incoming URL has an extension of .jsp, 50% of the time the static response is served.
{
"matchRules": [{
"matchURL": null,
"matches": [{
"matchType": "extension",
"matchValue": "jsp",
"matchOperator": "equals",
"negate": false,
"caseSensitive": false
}],
"start": 0,
"end": 0,
"disabled": false,
"type": "apMatchRule",
"useIncomingQueryString": false,
"passThroughPercent": "50",
"name": "RequiredNameField",
"id": null
}]
}
Audience Segmentation
Audience Segmentation provides traffic segmentation and stickiness without degrading performance, which is often beneficial for A/B and multivariate testing. This Cloudlet creates stable test populations by assigning a cookie value to the user based on the rules you define.
This Cloudlet supports a range match. When setting up a range match, enter the two numbers that comprise the range. If the random value assigned to an incoming request falls within this range (inclusive), the match is true.
You can only include one Range Match per rule.
Match rule example
For this example, if the incoming request is assigned a value between 1 and 25 (inclusive), the request is forwarded to the /sales/Q1 directory. Any query strings from the incoming request is appended to the forward request URL.
{
"matchRules": [{
"matches": [{
"matchType": "range",
"objectMatchValue": {"type": "range","value": [1,25]},
"matchOperator": "equals","negate": false,"caseSensitive": false}],
"start": 0,
"end": 0,
"disabled": false,
"type": "asMatchRule",
"forwardSettings": {
"originId": "originremote2",
"useIncomingQueryString": true,
"pathAndQS": "/sales/Q1/"},
"name": "Q1SalesTestPop",
"id": null
}]
}
Edge Redirector
Edge Redirector helps you more efficiently manage large numbers of redirects. By executing redirects at the Akamai Edge, you can reduce round trips to the origin and offload hits from your origin infrastructure.
Match rule example
For the following Edge Redirector match rule, any URL that uses the HTTP protocol, has a domain name of example.com, and includes test=null as a query string redirects to the following URL http://testredirect.akamai.com/test.html.
{
"matchRules": [{
"type": "erMatchRule",
"end": 0,
"id": 0,
"matchURL": null,
"matches": [{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "protocol",
"matchValue": "http",
"negate": false
},
{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "hostname",
"matchValue": "example.com",
"negate": false
},
{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "query",
"matchValue": "test=null",
"negate": false
}],
"name": "rule 1",
"redirectURL": "HTTP://testredirect.akamai.com/test.html",
"disabled": false,
"start": 0,
"statusCode": 302,
"useIncomingQueryString": false
}]
}
Forward Rewrite
Forward Rewrite helps you create, based on in-bound request information, human-readable and search engine optimization-friendly (SEO-friendly) URLs for dynamically-generated pages.
Match rule example
For this match rule, if the incoming URL has http for the protocol or the hostname includes example1.com, the forward URL has the following path appended to it: /test_images/simpleimg.jpg.
{
"matchRules": [{
"type": "frMatchRule",
"disabled": false,
"end": 0,
"id": 0,
"matchURL": null,
"forwardSettings": {
"pathAndQS": "/test_images/simpleimg.jpg",
"useIncomingQueryString": true },
"matches": [{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "protocol",
"matchValue": "http",
"negate": false
},
{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "hostname",
"matchValue": "example1.com",
"negate": false
}],
"name": "rule 1",
"start": 0
}]
}
Phased Release
Phased Release provides, at the edge, a mechanism to define a percentage of your visitors and direct them to a different origin while maintaining visitor stickiness. This Cloudlet can help facilitate a fast rollout of code changes to production with real users, allowing you to move some visitors to a new experience or deployment while retaining the flexibility to roll back immediately should you encounter challenges.
Match rule example
For this Phased Release example, 30% of the incoming requests from the 23.235.39.74 IP address are forwarded to the mynetstorage Cloudlet origin.
{
"matchRules": [{
"matches": [{
"matchType": "clientip",
"matchValue": "23.235.39.74",
"checkIPs": "CONNECTING_IP",
"matchOperator": "equals",
"negate": false,
"caseSensitive": false}],
"start": 0,
"end": 0,
"disabled": false,
"type": "cdMatchRule",
"forwardSettings": {
"percent": 30,
"originId": "mynetstorage"},
"name": "IP_39.74_rule",
"id": null
}]
}
Request Control
Request Control allows you to provide conditional access to your website or application by defining and managing allow lists and block lists based on a number of match criteria, including the IP address and geography associated with incoming requests.
Match rule example
For the following Request Control match rule, a request from the 72.246.0.0/16 or 192.0.2.0 address or from the United States are allowed through to the site.
{
"matchRules": [{
"type": "igMatchRule",
"end": 0,
"id": 0,
"matches": [{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "clientip",
"matchValue": "72.246.0.0/16 192.0.2.0",
"checkIPs": "CONNECTING_IP XFF_HEADERS",
"negate": false
},
{
"caseSensitive": false,
"matchOperator": "contains",
"matchType": "countrycode",
"matchValue": "US",
"checkIPs": "CONNECTING_IP",
"negate": false
}],
"name": "rule 1",
"disabled": false,
"allowDeny":"denybranded",
"start": 0
}]
}
Virtual Waiting Room
Virtual Waiting Room helps maintain business continuity for your dynamic application through the use of a waiting room page in high-demand situations. Virtual Waiting Room uses First In First Out (FIFO). FIFO is a fair request processing mechanism. Visitors who enter your waiting room first, are the first to leave and enter your origin. As the origin capacity allows, visitors are automatically sent to the origin from the waiting room. Wait time is displayed to the visitor and is updated. The wait time depends on the visitors position in the FIFO queue.
Match rule example
For the following Virtual Waiting Room match rule, if path has a match value of /shoppingABC* and the number of visitors allowed to enter the origin per second exceeds 500, visitors are sent to the virtual waiting room and placed in the FIFO queue.
"matchRules": [{
"type": "vwrMatchRule",
"matches": [{
"matchType": "path",
"matchValue": "/shoppingABC*",}],
"disabled": false,
"action": "FIFO",
"useIncomingQueryString": true,
"name": "Rule ABC",
"matchesAlways": true
}],
"configuration": {
"originNewVisitorLimit": 500
}
}