What are the URI, URL Param and HDR algorithms for; in which scenario are they used?

Short answer

URI, URL Param and HDR are self-persistent algorithms on an HTTP vService that select the server with the hash of a part of the request: URI uses the request path, URL Param a specified URL parameter, and HDR a specified HTTP header. The same value always goes to the same server; they are used to increase cache efficiency or to provide persistence per user or tenant. If the value is not in the request, the request is distributed to the servers in turn.

Algorithms

Algorithm	Hashed value	Additional field	Typical scenario
URI	Request path (the part before the ? character)	URI Character Length (required, 1–10000) · URI Depth (optional, 1–100)	Keeping the same content on the same server in cache or proxy servers
URL Param	The value of the specified URL parameter	URL Parameter to Use (required) · Check Post Parameters (off by default)	Persistence by ID such as ?user_id=, ?tenant=
HDR	The value of the specified HTTP header	HDR Name (required)	Persistence by header such as an API key or X-Tenant-ID

All three exist only on an HTTP vService; the algorithm-specific additional fields open in the form when the algorithm is selected. The Hash Consistency switch also appears in the same box (off by default).

How Does It Work?

• URI: URI Character Length determines how many characters of the path from the beginning, and URI Depth how many / levels, are included in the hash; if both are given, the limit reached first applies.
• URL Param: The parameter is searched for in the query string; if Check Post Parameters is on and the parameter is not in the query string, it is also searched for in the POST body.
• HDR: The header name is not case-sensitive.
• If there is no value: If the parameter or header is not present in the request, the request is distributed to the servers in turn; there is no persistence for these requests.
• Weight: The hash result is mapped according to the total Weight of the running servers; the Weight values are reflected in the distribution.
• If the number of servers changes: Most values shift to another server. If Hash Consistency is on, only a small portion changes place and no server receives more than 1.5 times the average load (What does the Hash Consistency option do in hash-based algorithms?).

In TR7

• Selection: vService → Details → LB Algorithm → Algorithm → URI, URL Param or HDR (Self-persistent).
• WEB-CLI: The values are urilen, urlparam and hdr; the additional fields are written with --uriLen, --uriDepth, --urlParamKey, --checkPost and --hdrName (distribution algorithm).
• Monitoring: The Load Balancer Management screen of the vService states the algorithm, its additional fields and that the algorithm pins the client to a server by itself.

Common Misconceptions

• "I turn on cookie persistence or SAM together with these algorithms." When a self-persistent algorithm is selected, the Persistence field is hidden.
• "URL Param keeps every request on the same server." Requests without the parameter are distributed in turn.
• "Hash distributes evenly." If there are few distinct values (e.g. a few tenants), some of the servers can stay empty.
• "When a server is added, everyone stays on the same server." While Hash consistency is off, when the number of running servers changes, most values shift to another server.

How it is done in the documentation

• HTTP (L7) vService · Algorithms
• HTTP (L7) vService · Algorithm-specific additional fields
• HTTP (L7) vService · Session Persistence

Related questions

• What do the entries marked "(Self-persistent)" in the algorithm list mean?
• How does Hash persistence work?
• What does the Hash Consistency option do in hash-based algorithms?