16. Set Headers

16.1. Set Request Headers

Configuration Definition: Subscriber
Configuration Application: Match Rule
Default Behavior: Off/Disabled
Limitations: Lua request headers and request header groups are mutually exclusive - only one is executed by nginx.
Version: 18.4

The Set Request Header feature allows the user to include a custom header in requests sent upstream to their origin. Defining a request header rule is done in two steps:

  1. Define a group of request headers and their values.
  2. Create a match rule that references the group of request headers defined in step 1.

The request header group is defined at the subscriber level and can be used by any property under that subscriber. This avoids having to define the same set of request headers for multiple properties. A request header group includes a list of header names and their associated values, an ID and a name that is used for reference. The ID is an internal reference that, once set, cannot be changed. Following is a sample request header group definition using the JSON schema:

"requestHeaderDefinitions": [
   {
     "headers": [
       {
         "name": "ReqHdr1",
         "value": "Req Value 1"
       },
       {
         "name": "ReqHdr2",
         "value": "Req Value 2"
       }
     ],
     "id": 10,
     "name": "1-ReqHeaderDef1"
   }

Request headers and their values are defined within the “headers” object. Request values can be set statically or dynamically using programmatic syntax. Locations (path match) are used to determine when and which custom HTTP request header definition is to be used.

Multiple HTTP request header groups can be defined with different HTTP request headers.

A request header definition is applied by creating a match rule (within the subscriber service image) that references the defined request header definition(s). Following is a sample match rule with a request header definition using the JSON schema:

"matchGroups": [
   {
     "id": 8456,
     "matchRules": [
       {
         "expression": "/",
         "features": {
           "reqHeaders": {
             "value": {
               "idList": [
                 10
               ]
             }
           }
         }
         "id": 84560
       }
     ]
   }
 ]

16.2. Set Response Headers

Configuration Definition: Subscriber
Configuration Application: Match Rule
Default Behavior: Off/Disabled
Limitations: Lua response headers and response header groups are mutually exclusive - only one is executed by Nginx.
Version: 17.5

The Set Response Header feature allows users to return a custom header in response to specific requests. Defining a response header rule is done as follows:

  1. Define a group of response headers and their values for specific response codes.
  2. Create a location definition that references the previously defined group of response headers.

The response header group is defined at the subscriber level and can be used by any property under that subscriber. This avoids having to define the same set of response headers for multiple properties. A response header group includes a list of response codes the response headers is returned in, a list of header names and their associated values, an ID and a name that is used for reference. The ID is an internal reference that, once set, cannot be changed. Following is a sample response header group definition using the JSON schema:

"responseHeaderDefinitions": [
   {
       "id": 1,
       "name": "RespHdrGroup"
       "statusAll": false,
       "statusCliError": false,
       "statusRedir": false,
       "statusSrvError": false,
       "statusSuccess": true
       "headers": [
           {
              "name": "lvlt-hdr"
              "value": ""ctl-cdn"
           }
       ],
       "customStatusCodes": []
    }
]

Attributes of a Response Header Defintion are as follows:

  • id: An integer value, must be unique across all responseHeaderDefinitions within a given service image
  • name: A descriptive name for the definition
  • statusAll: If true, this header group applies to all responses
  • statusCliError: If true, this header group applies to 4xx responses.
  • statusRedir: If true, this header group applies to 301,302,303,307 responses.
  • statusSrvError: If true, this header group applies to 5xx responses.
  • statusSuccess: If true, this header group applies to 2xx and 304 responses.
  • headers: A list of headers and their value to be returned
  • customStatusCodes: When set to true, includes a list of HTTP status codes that this header group allies to

Response headers and their values are defined within the “headers” object. Response values can be set statically or dynamically using programmatic syntax. Locations (path match) are used to determine when and which custom HTTP response header definition is to be used.

Multiple HTTP response header groups can be defined with different criteria (e.g., response codes) and HTTP response headers.

A response header definition is applied by creating a match rule (within the subscriber’s service image) that references the response header definition(s). Following is a sample match rule with a response header definition using the JSON schema:

"matchGroups": [
   {
     "id": 8456,
     "matchRules": [
       {
         "expression": "/",
         "features": {
           "respHeaders": {
             "value": {
               "idList": [
                 10
               ]
             }
           }
         }
         "id": 84560
       }
     ]
   }
 ]