Server Variables are variables of the form %{NAME_OF_THE_VARIABLE}. These can be used on the Rewrite directives to
replace and evaluate at runtime. Consider:
RewriteRule ^/tribestream$ %{ENV:tribestream-address} [P]
This rule will proxy to the value defined in the Environment Variable tribestream-address.
There are a lot of variables available to collect all kinds of information. TAG implements the same variable resolution as Apache Http Server. Check Expressions in.
Also, a few namespaces for variables are available in the form %{NAMESPACE:NAME_OF_THE_VARIABLE}. These namespaces
further enhance the resolution of custom values. At this time, TAG implements the following namespaces:
%{ENV:variable} - For System Environment Variables and Java System Properties
%{SSL:variable} - For SSL related information
%{HTTP:header} - To retrieve header values from the request
%{HEADER:header} - Same as %{HTTP:header}
%{JWT:property} - To retrieve properties in a JWT Claim.
%{OGNL:variable} - To resolve a variable based on a OGNL expression.
Use TAG autocompletion editor to your advantage to retrieve the full list of Server Variables available to use.
The RewriteCond directive defines a rule condition. One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met.
RewriteCond %{HTTP:environment} ^qly$
RewriteRule ^/my-api$ http://qly.my-api.biz [P]
This rule will inspect the HTTP header environment and if it matches the value qly it will evaluate the next
RewriteRule directive in the rule set. If the RewriteRule directive also matches the URL pattern, then TAG will issue
a Proxy request to http://qly.my-api.biz.
If multiple RewriteCond directives are specified, all must match for the RewriteRule to be evaluated:
RewriteCond %{HTTP:environment} ^qly$ (1)
RewriteCond %{HTTP:version} ^1$ (2)
RewriteRule ^/my-api$ http://qly.my-api.biz/v1 [P] (3)
| 1 | Check for a qly value in the header environment |
| 2 | Check for a 1 value in the header version |
| 3 | If both the headers environment and version contain the values qly and 1 and the request pattern
matches my-api, then the request is proxied to http://qly.my-api.biz/v1. |
It is possible to validate only one condition when multiple are specified:
RewriteCond %{HTTP:version} ^2$ [OR] (1)
RewriteCond %{HTTP:version} ^1$ (2)
RewriteRule ^/my-api$ http://qly.my-api.biz/ [P] (3)
| 1 | Check for a 1 value in the header version |
| 2 | Check for a 2 value in the header version |
| 3 | If any of the values 1 or 2 is sent in the header version and the request pattern matches my-api, then
the request is proxied to http://qly.my-api.biz/. |
The RewriteMap directive defines an external function which can be called in the context of RewriteRule or RewriteCond directives to perform rewriting that is too complicated, or too specialized to be performed just by regular expressions.
RewriteMap lc int:tolower
RewriteRule ^(.*)$ /${lc:$1} [P]
A Rewrite Map requires the directive RewriteMap followed by a name lc a map type int and a map source tolower.
This route will proxy any address to all lowercase version of the original request address. Using the $1
back-reference, the lower case function is applied with ${lc:$1}.
At this time, TAG only supports a few functions:
| Function | Description |
|---|---|
int:tolower |
Converts the function argument to all lower case. |
int:toupper |
Converts the function argument to all upper case. |
int:escape |
Translates special characters in the function argument to hex-encodings. |
int:unescape |
Translates hex-encodings in the function argument back to special characters. |
jwt:PROFILE_NAME |
Resolve JWT properties for the JWT associated with the profile |
The RewriteMap directive can occur more than once. For each mapping-function use one RewriteMap directive to declare its function.