You can specify HTTP request modifications by using conditions. In releases before 7.40 conditions had a simple format. With the simple format a condition can be linked to one single modification action.
Use the following syntax in the action file to link one modification action to a condition.
Syntax of a Single Request Modification
if <string> <compop> <pattern> [op] <rule>
Two further options are available with Release 7.40. Conditions can be linked to a processing block and can contain branches.
Syntax Processing Block
Multiple modification actions can be specified in one processing block. If the condition is true, all the modification actions defined there are executed when the action file is read. If the condition does not apply, the complete processing block is skipped. Use the following syntax in the action file to define a processing block:
if <string> <compop> <pattern> [op] begin <rules> end
Syntax Branch
Two modification actions are combined in one branch. If the condition applies, modification actions defined before "else" are executed. If the condition does not apply, all modification actions defined after else are executed. You also have the option not to define any entries for <rule/rules>, or to comment out modification actions by including a preceding "#" character.
To branch precisely two modification actions, use the following syntax in the action file:
if <string> <compop> <pattern> [op] <rule> else <rule>
If you want to specify more than two modification actions, use the following syntax in the action file:
if <string> <compop> <pattern> [op] begin <rules> else <rules> end
Explanation of the Syntax
<string> |
A fixed character string or element of the HTTP request (header field, form field, system-defined values). Access with variables. |
<compop> |
Comparison operation; the following comparison operations are valid:
All comparison operations can be negated by using a preceding "!". The comparison operators are not case sensitive. All names of comparison operations are not case sensitive. |
<pattern> |
comparison value used for the comparison. A comparison value can be, for example, a regular expression or an IP address. |
[op] |
You can use operators to link conditions together. Possible operators are "and" and "or". Operators are not case sensitive (e.g. OR = Or = or = oR). Unlike programming languages the operators here have equal precedence. Operators are processed from left to right. The use of operators is optional. |
Examples of the use of conditions:
Example A:
if %{HTTP_HOST} regimatch *.wdf.sap.com [and] if %{SERVER_PORT} = 80 SetHeader clientProtocol http
If the host name (value of the HTTP host header HTTP_HOST) in the HTTP request ends with .wdf.sap.com and the HTTP port of port 80 is (http://xxx.wdf.sap.com:80/...), the header field clientProtocol is set to the value http.
Example B:
If %{REQUEST_METHOD} !stricmp "GET" [and] If %{REQUEST_METHOD} !stricmp "POST" RegForbiddenUrl ^/(.*) -
Only requests with GET and POST are permitted as methods. All other requests are rejected.
Example C:
# Rewrite Rules for ICM If %{REQUEST_METHOD} stricmp "TRACE" RegForbiddenUrl ^/(.*) -
HTTP requests with the TRACE method are rejected.
Example D:
if %{HEADER:USER-AGENT} !regimatch Mozilla/4.0* RegForbiddenUrl (.*) -
Only requests containing the character string Mozilla/4.0 (not case sensitive) are permitted.
Example E:
If %{SERVER_PROTOCOL} !stricmp "https" RegIRedirectUrl /sap/ (.*) https://%{HTTP_HOST}/sap/ $1 [code=permanent]
If the protocol used is not HTTPS, the request is reformulated for HTTPS.
Example F:
If %{REMOTE_ADDR} ipmatch 10.18.0.0/16 SetHeader test matched
Comparison of the remote IP address with Ipv4 mask "10.18.0.0/16" (the first 16 bits are relevant)
Example G:
If %{REMOTE_ADDR} !ipmatch 2001:db8::1428:57ab/32 Set Header test matched
Comparison of the remote IP address with Ipv6 mask "2001:db8::1428:57ab/32" (the first 32 bits are relevant)