HTTP Request Policy
Overview
HTTP request policies allow manipulation of HTTP requests. These requests may be modified before they are forwarded to the server, used as a basis for content switching, or discarded. The HTTP request policies may only be applied to a layer 7 virtual service configured with an HTTP profile. The table below lists the match criteria available under HTTP request, as well as the actions that can be configured to occur upon a match being made.
Note: This feature is supported for IPv6 in NSX Advanced Load Balancer.
| Match | Client IP: Client IP address or a group of client addresses.
|
| Service Port: The ports the virtual service is listening on. | |
| Protocol Type: HTTP or HTTPS. Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2 |
|
| HTTP Method: The method used by the client request. The match is true if any one of the methods that an administrator specifies is true. The options available are GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, and CONNECT. Starting with NSX Advanced Load Balancer version 18.2.3, you can also choose from the additional options: PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. |
|
| HTTP Version: True if the client version is .9, 1.0, or 1.1 | |
Path: The path or a group of paths. In accordance with RFC 3986, a path is empty or starts with a forward slash. For the beginswith and equals match operators in an HTTP request match policy, the match string needs to begin with a forward slash to result in a match.Example: In https://www.avinetworks.com/marketing/index.html?a=1&b=2 the path is /marketing/index.html. | |
| Query: A query or a group of queries. Do not add the leading ‘?’ or ‘&’ characters to a match. Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2 Note: Starting with NSX Advanced Load Balancer version 22.1.3, new options are added in the match criteria for Query. For more information, see HTTP Policy QueryMatch. |
|
| Headers: True if a header exists, or if it exists and contains a specified value | |
| Cookie: True if a cookie exists, or if it exists and contains a specified value | |
| Host Header: The request’s host header. Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2 |
|
| Action | Redirect URL: Redirects a client to a different protocol, port, host, or path. By default the host, path, and query are not altered unless an administrator populates those fields. The path field does not require a leading “/” slash character. To create a simple HTTP to HTTPS redirect, simply set the protocol to HTTPS. NOTE: The redirect action may not be stacked with other actions. |
| Modify Header: Allows adding, replacing, or removing of an HTTP header or cookie. Note: Starting with NSX Advanced Load Balancer version 22.1.1, Is Sensitive field is added within the ‘Modify header’ action to mask any custom value that is sensitive. |
|
| Rewrite URL: Similar to ProxyPass functionality, this action allows for the client’s requested URL to be rewritten into a URL that the server understands. For instance, the client should usewww.avinetworks.com/sales, while the server may be configured for sales.avinetworks.com. The path field does not require a leading "/" slash character. | |
| Content Switch: Forward matched requests to a pool, or a specific server with that pool. Alternatively, NSX Advanced Load Balancer can serve an HTTP response using HTTP status code 200 (success), 403 (unauthorized), 404 (file not found), or 429 (too many requests). A default page is sent for each of these status codes, or a custom html file may uploaded. Note: Starting with NSX Advanced Load Balancer version 21.1.3, you can upload any type of file as a local response. It is recommended to configure a local file using the UI. To update the local file using API, encode the base64 file out of band and use the encoded format in the API. |
Is Sensitive
Option to mask the custom values in ‘Modify Header’
Starting from NSX Advanced Load Balancer version 22.1.1, Is Sensitive field is added within Modify Header action to add any custom value which is sensitive.
The sensitive field (Is Sensitive) is a flag in HTTP header value which determines if the custom value has to be marked sensitive or not. If you check Is Sensitive field, then the custom value in Modify header option in action for HTTP Policy Set will be masked. An example is shown in the screenshot below:
Note: The Is Sensitive is an immutable field, it can only be set or unset during creation of the HTTP policy.
As the header values are masked, updating an existing header can be difficult for the admins. To simplify this, NSX Advanced Load Balancer assigns an index, that is, an integer value to identify all the headers uniquely as shown in the screenshot above. This helps to remove the ambiguity. The index is auto assigned by NSX Advanced Load Balancer. If there is any requirement to change the index, it can be done using CLI or API and you need to ensure that the index should be a unique value.
The CLI for setting sensitive field for custom values in HTTP Policies is as follows:
+------------------------+----------------------------------------------------+
| Field | Value |
+------------------------+----------------------------------------------------+
| uuid | httppolicyset-14be5dde-8ff2-4891-a930-a81b6f547d9b |
| name | test-HTTPPolicySet-0 |
| http_request_policy | |
| rules[1] | |
| name | Rule 1 |
| index | 1 |
| enable | True |
| match | |
| vs_port | |
| match_criteria | IS_IN |
| ports[1] | 80 |
| hdr_action[1] | |
| action | HTTP_ADD_HDR |
| hdr | |
| name | pqr |
| value | |
| val | <sensitive> |
| is_sensitive | True |
| hdr_index | 1 |
| is_internal_policy | False |
| tenant_ref | admin |
+------------------------+----------------------------------------------------+
HTTP Policy QueryMatch
In HTTP policies, one of the parameters that can match against is the query string in the URI. QueryMatch is similar to other match targets in the following ways:
-
It is used to match the query string against a list of custom strings or string groups.
-
It is used to copy the query string into the action rules (Redirect or Rewrite URL actions) using the Keep Query knob.
This section details the enhancements made in 22.1.3.
Addition of Match Criteria
Starting with NSX Advanced Load Balancer version 22.1.3, additional match criteria for the Query in the HTTP Policies is supported. Prior to the NSX Advanced Load Balancer version 22.1.3, only QUERY_MATCH_CONTAINS was supported. Following are the new match operations supported for Query match:
| Match Operation | Description |
|---|---|
| QUERY_MATCH_CONTAINS | Query string contains the configured value(s) |
| QUERY_MATCH_DOES_NOT_CONTAIN | Query string does not contain the configured value(s) |
| QUERY_MATCH_EXISTS | Check if the query string is present in the URI |
| QUERY_MATCH_DOES_NOT_EXIST | Check if the query string is absent (or empty) |
| QUERY_MATCH_BEGINS_WITH | Query string begins with the configured value(s) |
| QUERY_MATCH_DOES_NOT_BEGIN_WITH | Query string does not begin with the configured value(s) |
| QUERY_MATCH_ENDS_WITH | Query string ends with the configured value(s) |
| QUERY_MATCH_DOES_NOT_END_WITH | Query string does not end with the configured value(s) |
| QUERY_MATCH_EQUALS | Query string equals the configured value(s) |
| QUERY_MATCH_DOES_NOT_EQUAL | Query string does not equal the configured value(s) |
| QUERY_MATCH_REGEX_MATCH | Query string matches the configured regular expression |
| QUERY_MATCH_REGEX_DOES_NOT_MATCH | Query string does not match the configured regular expression |
Notes:
- Regex matching uses string groups exclusively.
- Regex matching can have up to ten capture groups.
Matching Encoded Strings
Starting with NSX Advanced Load Balancer version 22.1.3, the Match Decoded String option for the Query_Match is supported (as earlier supported for path match). The Match Decoded String option allows user to specify whether to match against an encoded (UTF-8) or decoded query string. By default, the option is selected.
Example 1:
If Match_decoded is unmarked and URI /hello/test?efg=%21efg is sent, the rule will match. Whereas if URI /hello/test?efg=!efg is sent, the rule will not match.
Example 2:
If Match_decoded is marked for the strings hello/test?efg=!efg or hello/test?efg=%21efg, both will match because the string will be converted to hello/test?efg=!efg in both cases.
Document Revision History
| Date | Change Summary |
|---|---|
| January 30, 2023 | Added HTTP Policy QueryMatch for 22.1.3 |
| July 15, 2022 | Added Is Sensitive section for 22.1.1 |