Conditions define the criteria that incoming requests must meet for a listener rule to take effect. If a request matches the conditions for a rule, the request is handled as specified by the rule's actions. Each rule condition has a type and configuration information. Application Load Balancers support the following condition types for listener rules.
Condition typeshost-header
Route based on the host name of each request. For more information, see Host conditions.
http-header
Route based on the HTTP headers for each request. For more information, see HTTP header conditions.
http-request-method
Route based on the HTTP request method of each request. For more information, see HTTP request method conditions.
path-pattern
Route based on path patterns in the request URLs. For more information, see Path conditions.
query-string
Route based on key/value pairs or values in the query strings. For more information, see Query string conditions.
source-ip
Route based on the source IP address of each request. For more information, see Source IP address conditions.
Each rule can optionally include up to one of each of the following conditions: host-header, http-request-method, path-pattern, and source-ip. Each rule can also optionally include one or more of each of the following conditions: http-header and query-string.
You can specify up to three match evaluations per condition. For example, for each http-header condition, you can specify up to three strings to be compared to the value of the HTTP header in the request. The condition is satisfied if one of the strings matches the value of the HTTP header. To require that all of the strings are a match, create one condition per match evaluation.
You can specify up to five match evaluations per rule. For example, you can create a rule with five conditions where each condition has one match evaluation.
You can include wildcard characters in the match evaluations for the http-header, host-header, path-pattern, and query-string conditions. There is a limit of five wildcard characters per rule.
Rules are applied only to visible ASCII characters; control characters (0x00 to 0x1f and 0x7f) are excluded.
For demos, see Advanced request routing.
Host conditionsYou can use host conditions to define rules that route requests based on the host name in the host header (also known as host-based routing). This enables you to support multiple subdomains and different top-level domains using a single load balancer.
A hostname is not case-sensitive, can be up to 128 characters in length, and can contain any of the following characters:
AâZ, aâz, 0â9
- .
* (matches 0 or more characters)
? (matches exactly 1 character)
You must include at least one "." character. You can include only alphabetical characters after the final "." character.
Example hostnamesexample.com
test.example.com
*.example.com
The rule *.example.com matches test.example.com but doesn't match example.com.
Example host header condition for the AWS CLIYou can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a host header that matches the specified string.
[
{
"Field": "host-header",
"HostHeaderConfig": {
"Values": ["*.example.com"]
}
}
]You can use HTTP header conditions to configure rules that route requests based on the HTTP headers for the request. You can specify the names of standard or custom HTTP header fields. The header name and the match evaluation are not case-sensitive. The following wildcard characters are supported in the comparison strings: * (matches 0 or more characters) and ? (matches exactly 1 character). Wildcard characters are not supported in the header name.
When the Application Load Balancer attribute routing.http.drop_invalid_header_fields is enabled, it will drop header names that don't conform to the regular expressions (A-Z,a-z,0-9). Header names that don't conform to the regular expressions can also be added.
You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a User-Agent header that matches one of the specified strings.
[
{
"Field": "http-header",
"HttpHeaderConfig": {
"HttpHeaderName": "User-Agent",
"Values": ["*Chrome*", "*Safari*"]
}
}
]You can use HTTP request method conditions to configure rules that route requests based on the HTTP request method of the request. You can specify standard or custom HTTP methods. The match evaluation is case-sensitive. Wildcard characters are not supported; therefore, the method name must be an exact match.
We recommend that you route GET and HEAD requests in the same way, because the response to a HEAD request may be cached.
Example HTTP method condition for the AWS CLIYou can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests that use the specified method.
[
{
"Field": "http-request-method",
"HttpRequestMethodConfig": {
"Values": ["CUSTOM-METHOD"]
}
}
]You can use path conditions to define rules that route requests based on the URL in the request (also known as path-based routing).
The path pattern is applied only to the path of the URL, not to its query parameters. It is applied only to visible ASCII characters; control characters (0x00 to 0x1f and 0x7f) are excluded.
The rule evaluation is performed only after URI normalization occurs.
A path pattern is case-sensitive, can be up to 128 characters in length, and can contain any of the following characters.
AâZ, aâz, 0â9
_ - . $ / ~ " ' @ : +
& (using &)
* (matches 0 or more characters)
? (matches exactly 1 character)
If the protocol version is gRPC, conditions can be specific to a package, service, or method.
Example HTTP path patterns/img/*
/img/*/pics
/package
/package.service
/package.service/method
The path pattern is used to route requests but does not alter them. For example, if a rule has a path pattern of /img/*, the rule forwards a request for /img/picture.jpg to the specified target group as a request for /img/picture.jpg.
You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a URL that contains the specified string.
[
{
"Field": "path-pattern",
"PathPatternConfig": {
"Values": ["/img/*"]
}
}
]You can use query string conditions to configure rules that route requests based on key/value pairs or values in the query string. The match evaluation is not case-sensitive. The following wildcard characters are supported: * (matches 0 or more characters) and ? (matches exactly 1 character).
Example query string condition for the AWS CLIYou can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a query string that includes either a key/value pair of "version=v1" or any key set to "example".
[
{
"Field": "query-string",
"QueryStringConfig": {
"Values": [
{
"Key": "version",
"Value": "v1"
},
{
"Value": "*example*"
}
]
}
}
]You can use source IP address conditions to configure rules that route requests based on the source IP address of the request. The IP address must be specified in CIDR format. You can use both IPv4 and IPv6 addresses. Wildcard characters are not supported. You cannot specify the 255.255.255.255/32 CIDR for the source IP rule condition.
If a client is behind a proxy, this is the IP address of the proxy, not the IP address of the client.
This condition is not satisfied by the addresses in the X-Forwarded-For header. To search for addresses in the X-Forwarded-For header, use an http-header condition.
You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a source IP address in one of the specified CIDR blocks.
[
{
"Field": "source-ip",
"SourceIpConfig": {
"Values": ["192.0.2.0/24", "198.51.100.10/32"]
}
}
]RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4