Can I route based on an HTTP Header, cookie or query parameter?

Short answer

Yes, on the HTTP vService. HTTP Header, User Cookie Name and Query Parameter conditions are created and bound to Conditional Backend Services blocks; the value is matched with Exact match, Start, End, Includes or Regex, and with Is present only the presence of the header, the cookie or the parameter is checked. Dynamic Condition and Dynamic List are used to evaluate more than one variable together or to search for a value in a long list.

Problem: The Decision Depends on a Value Inside the Request

To send beta users, a specific customer, an API version or test requests to separate servers, a header, a cookie or a URL parameter of the request needs to be checked. The requests are to be directed to different Backend Services based on these values.

Solution: Three Methods

All three methods set up the same structure (condition + conditional block); the difference is how the condition is defined.

Your situation	Suitable method
Checking a single header, cookie or parameter is enough	Method 1: HTTP header / User Cookie Name / Query parameter condition
I want to evaluate more than one value together or search for the value in a long list	Method 2: Dynamic condition / Dynamic list
I want to set up cookie-based routing from the command line	Method 3: WEB-CLI

Method 1: HTTP Header / User Cookie Name / Query Parameter Condition Recommended

• How it works The header, cookie or parameter value in the request is compared with the condition; a matching request goes to the Backend Services of the block, the others go to the next blocks or to Default Backend Services.
• Where it is openedLoad Balancer → Conditions · vService form → + Conditional backend services
• Requirement The target servers being defined as Backend Services
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Prepare the target Backend Services (if needed)

If the servers the block will route to (e.g. beta servers) are not yet defined as Backend Services in TR7, they are added first; if they are defined, this step is skipped. With Load Balancer → Backend Services → Add, Backend Service Name and Address are entered for each server and a Health Check profile is selected. Details: How is a Backend Service added; which information is required?

2

Adım 2 Open the condition form

The Load Balancer → Conditions → Add steps are followed; the form is described in the Conditions · How to Add? section.

3

Adım 3 Define the condition

Condition Name is entered, and one of the following is selected as Criteria according to the value to be checked:

Criteria	Fields filled in	Example
HTTP Header	Header Name (Request in the selector on the left, the header name), matching method, Query	Request · X-Canary, Exact match, true
User Cookie Name	Cookie Name, matching method, Query	beta, Exact match, 1
Query Parameter	Query Parameter (the parameter name), matching method, Query	version, Exact match, 2

The matching method is Exact Match by default; if Is present is selected, the Query field disappears and only whether the header, the cookie or the parameter is present in the request is checked. If the case difference is to be ignored, Case Insensitive is checked (off by default). If Response is selected in the selector to the left of Header name, the condition checks the response header; although it can be selected in a conditional block, it never matches, because the Backend Service is selected at the request stage.

4

Adım 4 Save the condition

The Add button is clicked.

5

Adım 5 Open the vService edit form

The Load Balancer → Load Balancer vService List steps are followed and the HTTP vService is opened.

6

Adım 6 Add a conditional block

The + Conditional backend services button in the Default Backend Services table is clicked (Conditional Backend Services).

7

Adım 7 Select the condition and the target

The condition is selected in the Select Conditions field of the block, and the target Backend Services (or Backend Group) in the Backend Service selector.

8

Adım 8 Save

The Save button is clicked.

Verification

1RoutingTR7 side

On the Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP Logs screen, the Backend Service that responded to the request is checked (Viewing HTTP Logs). For the record to be created, the LOG field must be on in the vService.

ExpectedRequest carrying the value → Backend Service of the block · others → Default Backend Services

2Request testClient side

The same request is sent with and without the value; it is seen that the responses come from different Backend Services.

Commandcurl -s -H "X-Canary: true" http://203.0.113.10/ · curl -s --cookie "beta=1" http://203.0.113.10/ · curl -s "http://203.0.113.10/?version=2"

ExpectedThe request carrying the value receives a response from the Backend Service of the block

Method 2: Dynamic Condition / Dynamic List

• How it worksDynamic Condition compares the value of a Smart Variable with an operator (e.g. equals, contains, in range); Dynamic List searches for the value of a Smart Variable (e.g. a header or a cookie) in a long list that is entered.
• Where it is openedLoad Balancer → Conditions → Dynamic Condition / Dynamic List
• Requirement The target servers being defined as Backend Services
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the condition form

The Load Balancer → Conditions → Add steps are followed.

2

Adım 2 Define the condition

When Criteria = Dynamic Condition is selected, the Smart Variable to be compared is entered in the Query Key field, the operator in the Operator field, and the comparison value the operator requires. When Criteria = Dynamic list is selected, the Smart Variable to be searched (the client IP address by default) is entered in the Key to Search field, along with the Search Method, and the values in the List field.

3

Adım 3 Save the condition

The Add button is clicked.

4

Adım 4 Bind to the conditional block

Steps 5–8 of Method 1 are applied: the vService is opened, a block is added with + Conditional backend services, this condition is selected in the Select Conditions field, and the Save button is clicked.

Verification

1RoutingTR7 side

As in Method 1, the Backend Service that responded to the request is checked on the HTTP Logs screen.

ExpectedRequest that fits the condition → Backend Service of the block

Method 3: WEB-CLI

• How it works The User Cookie Name condition and the conditional block are defined from the command line. HTTP header and Query parameter conditions are created from the interface (Method 1); the created condition can be bound to the block with steps 2–4 of this method.
• Where it is opened TR7 WEB-CLI → lb condition · lb service
• Requirement WEB-CLI access; the target Backend Services being defined
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Add the cookie condition

lb condition add criteria user_cookie cookieName beta query 1 --name beta-cookie

The matching is exactMatch by default; for another method, --content_placement start, end, sub or regex is added.

2

Adım 2 Get the condition ID

lb condition list

The ID of the condition (the value starting with lbConditions-) is taken from the output; the block recognizes the condition by this ID, not by its name.

3

Adım 3 See the existing blocks

lb service show <vService>

The number of blocks in the dynamicBackendList list is seen; for the new block, the first empty index is used (0 if there are no blocks). If an occupied index is written, the block at that index is replaced.

4

Adım 4 Add the block

For the case where the vService has no conditional block yet (index 0):

lb service update id <vService> --dynamicBackendList.0.cond "<condition-id>" --dynamicBackendList.0.beList.0 <backend-service>

In place of <backend-service>, the name of the Backend Service or of the Backend Group is written.

Verification

1Block recordTR7 side

The vService is displayed again; the routing is checked with the verification cards of Method 1.

Commandlb service show <vService>

ExpectedNew block in dynamicBackendList

Common Mistakes

• Selecting Response in Header name. The Backend Service selection is made at the request stage; a condition that checks the response header never matches, even though it appears in the conditional block list. For routing, Request is selected.
• Not considering what happens when the value does not arrive. Requests that do not carry the header, the cookie or the parameter go to the next block or to Default Backend Services.
• Overlooking case sensitivity. Matching is case-sensitive by default.
• Using these values alone for a security decision. The header, the cookie and the parameter can be changed by the client; for an access restriction, they are used together with criteria that cannot be changed, such as the source IP or authentication.
• Binding the condition by its name in WEB-CLI. --dynamicBackendList.N.cond expects the condition ID.

How it is done in the documentation

• HTTP Header · Content Matching Method
• User Cookie Name · Cookie Name
• Query Parameter · Query Parameter
• Dynamic Condition · Query Key

Related questions

• What is Content Switching?
• How do I combine multiple conditions with AND / OR?
• What are Dynamic Condition and Dynamic List used for?