Action Types

There are several types of actions related to HTTP headers and HTTP cookies. Different fields are configurable per action, depending on the action type. For actions that require a matching header (e.g., type "Rewrite Header Value"), the two patterns for header name and header value must both match. If one pattern is empty, only the other pattern is considered.

Note that rewrite variables and backreferences to matching groups may be used within all rewrite rules.

Adds the configured header unconditionally. Existing headers with the same name are not changed or removed.

Adds the configured header only if a header with the same name is not present. A header is considered present if its name (case-insensitively) equals the configured header name.

Adds the configured header. If a header with the same name is already present, its value is replaced by the configured value. A header is considered present if its name (case-insensitively) equals the configured header name.

The matching header is removed if the mapping's threat handling mode is "Block".
The matching header is not removed if the mapping's threat handling mode is "Log only".

A request is redirected if a header matches. This action type is only available for requests. A redirect status code must be specified for each entry.

These are the most important codes:

• 301 Moved Permanently - This and all future requests should be directed to the given URI.
• 302 Found - This is an example of industry practice contradicting the standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviors. However, some Web applications and frameworks use the 302 status code as if it were the 303
• 303 See Other - The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.

For a comprehensive list see here.

A request is redirected if its origin matches the specified geographical regions. This action type is only available for requests. A redirect status code must be specified for each entry (see action type "Header Redirect").

For each action, a list of origin continents and countries can be specified.

The continent codes are:

• AF: Africa
• AN: Antarctica
• AS: Asia
• EU: Europe
• NA: North America
• OC: Oceania
• SA: South America

The country codes correspond to the Alpha-2 codes in the ISO 3166-1 standard.

If more than one code is specified in a field, the rule applies if any of the regions is matched (OR combination). However, the continent and country conditions must both match in order for the request to be redirected (AND combination). The continent and country conditions can be inverted individually.

Redirect all requests from the DACH region:

• Continent codes: empty
• Country codes: "DE, CH, AT, LI", not inverted

Redirect all requests from North and South America, except those from Brazil and Canada:

• Continent codes: "NA, SA", not inverted
• Country codes: "BR, CA", inverted

For matching headers, the value is replaced by the new value.

For matching cookie names the following attributes can be changed:

• Cookie Domain
• Cookie Path
• Cookie Secure Flag
  Auto: the "Secure" attribute is set if HTTPS is enabled on the virtual host and disabled otherwise.
• Cookie HttpOnly Flag
  Auto: the „HttpOnly“ attribute is automatically set for encrypted cookies. For passthrough cookies, the „HttpOnly“ attribute is not modified.

It is only possible to rewrite passthrough cookies and encrypted cookies.

Matching Set-Cookie header values are rewritten. The whole value of the Set-Cookie header is rewritten. It is only possible to rewrite passthrough cookies and encrypted cookies.