Can I rewrite the URL path before it reaches the backend (rewrite)?

Short answer

Yes. The Set Path action changes the path of the request before forwarding it to the Backend Service; the client is not redirected, the address bar does not change, and the request continues to be processed. Adding or removing a prefix, suffix and find-and-replace operations are prepared with Path Operation Shortcuts; the New Path Info field can also be written manually with Smart Variable and functions. If the query string will also change, Set Path + Query is used, and URL Normalization is used to bring the path to a standard form. Path conditions and TR7 logs see the path as it was before it was rewritten.

Problem: The External Address and the Path the Application Expects Are Different

While an address such as /api/v1/... is offered to users, the application may expect /v1/..., or an old application may work with a different path structure. Without the address the user sees changing, the request needs to go to the Backend Service with the path the application expects.

Solution: Five Methods

All of the methods work only on an HTTP vService and at the request stage. Rewrite operations do not end the request; the actions that come after them in the Actions list and the Backend Service selection continue to run. Since Path conditions (including Conditional Backend Services) evaluate the original form of the path, the server selection is not broken even if the prefix is removed from a request sent to separate servers with an /api/ condition.

Your situation	Suitable method
Adding/removing a prefix/suffix, find-and-replace	Method 1: Set Path + Path Operation Shortcuts
A custom path that cannot be prepared with the shortcuts	Method 2: Writing New Path Info manually
The query string will also change along with the path	Method 3: Set Path + Query
Spelling differences such as repeated slashes, ./.. segments	Method 4: URL normalization
From the command line	Method 5: WEB-CLI

Method 1: Set Path + Path Operation Shortcuts Recommended

• How it works The value entered in the shortcut window is converted into a New Path Info expression; e.g. Remove prefix /api → %PATH.STRREPLACE(^/api,).
• Where it is openedLoad Balancer → Actions → Set Path → Path Operation Shortcuts
• Requirement A condition that separates the requests whose path will change (Set Path without a condition is applied to all requests)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the condition form

Load Balancer → Conditions → Add is clicked (how to add).

2

Adım 2 Define the Path condition

Criteria = Path, match Start, and the value /api/ are entered. Writing the value with the trailing / prevents requests such as /api and /apiv2/… from being trimmed by mistake (table below).

3

Adım 3 Save the condition

Add is clicked.

4

Adım 4 Open the action form

Load Balancer → Actions → Add is clicked (how to add).

5

Adım 5 Define the action

Action Name is entered, and Action Type = Set Path is selected.

6

Adım 6 Apply the shortcut

On the Path Operation Shortcuts row, Remove prefix is clicked; in the window that opens, Prefix to remove = /api is entered and confirmed. The shortcut fills in the New Path Info field. Other shortcuts: Add prefix (default value /api), Add suffix / Remove suffix (default .html), Find & replace (default /old → /new, replaces all occurrences).

7

Adım 7 Select the condition

In the Conditions field, the condition from step 2 is selected. To count how many times the change is applied, Hit Counter is turned on (off by default).

8

Adım 8 Save the action

Add is clicked.

9

Adım 9 Edit the vService

On the Load Balancer → Load Balancer vService List screen, the HTTP vService is selected and Edit is clicked.

10

Adım 10 Add the action to the Actions field

The action is selected in the Details → Actions field.

11

Adım 11 Save

Save is clicked. The change is applied without dropping open connections; in a cluster, it is also sent to the peer device with the default auto-sync (if Manual Sync Mode is on, with Synchronize).

The result of the Remove prefix /api expression (%PATH.STRREPLACE(^/api,)) on example requests:

Request path	Path Start /api/ condition	Path going to the Backend Service
/api/v1/users	Matches	/v1/users
/api/	Matches	/
/api	Does not match	/api (unchanged)
/apiv2/x	Does not match	/apiv2/x (unchanged; without the condition, it would become v2/x)
/v1/api/x	Does not match	/v1/api/x (^ targets only the leading prefix)

The query string is preserved in Set Path: the /api/v1/users?page=2 request goes as /v1/users?page=2.

Verification

1Access logBackend Service side

curl -s https://www.example.com/api/v1/users is sent; the path the request reached is checked in the access log of the Backend Service.

ExpectedGET /v1/users

2CountTR7 side

If Hit Counter is on, the count of the action increases on the Action Hits tab of the vService dashboard. HTTP Logs shows the original address sent by the client (/api/v1/users).

ExpectedThe count increases · the original path in the log

Method 2: Writing New Path Info Manually

• How it works The desired path is built by combining fixed text, Smart Variables and functions; e.g. /v2 + Path/page of the request [URI].
• Where it is openedLoad Balancer → Actions → Set Path → New Path Info
• Requirement The resulting path starts with / (the form does not check this)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the action form

Load Balancer → Actions → Add is clicked.

2

Adım 2 Select the action type

Action Type = Set Path is selected.

3

Adım 3 Write the path

The New Path Info field comes filled with /prefix + the Path/page of the request [URI] variable. /v2 is written instead of /prefix; if needed, other variables and functions are added with fx. The result must start with /.

4

Adım 4 Select the condition

The condition is selected in the Conditions field.

5

Adım 5 Save the action

Add is clicked.

6

Adım 6 Edit the vService

The vService is opened with Edit.

7

Adım 7 Add the action to the Actions field

The action is selected in the Details → Actions field.

8

Adım 8 Save

Save is clicked.

Verification

1Access logBackend Service side

curl -s https://www.example.com/rapor/2024

ExpectedGET /v2/rapor/2024

Method 3: Set Path + Query

• How it works The path and the query string are rewritten together; the original query is preserved only if the Request query variable is added to the expression.
• Where it is openedLoad Balancer → Actions → Set Path + Query
• Requirement None
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the action form

Load Balancer → Actions → Add is clicked.

2

Adım 2 Define the action

Action Type = Set Path + Query is selected.

3

Adım 3 Write the path and the query

The path and the query are written together in the New Path Info field; in this type, the shortcuts automatically add the Request query variable to the end of the expression. Detailed comparison: What is the difference between Set Path and Set Path + Query?

4

Adım 4 Select the condition

The condition is selected in the Conditions field.

5

Adım 5 Save the action

Add is clicked.

6

Adım 6 Edit the vService

The vService is opened with Edit.

7

Adım 7 Add the action to the Actions field

The action is selected in the Details → Actions field.

8

Adım 8 Save

Save is clicked.

Verification

1Access logBackend Service side

The path and the query are seen together in the access log of the Backend Service.

ExpectedThe rewritten path and query

Method 4: URL Normalization

• How it works The path is brought to a standard form: repeated slashes are merged, . and .. segments are resolved, the percent-encoding of unreserved characters is decoded, and query parameters can be sorted by name.
• Where it is openedLoad Balancer → Actions → URL Normalization
• Requirement At least one option is checked
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the action form

Load Balancer → Actions → Add is clicked.

2

Adım 2 Define the action

Action Type = URL Normalization is selected.

3

Adım 3 Check the options

The options that are needed are checked in the Normalization list: Merge slash characters, Re-evaluate path in accordance with one dot (.), Re-evaluate path in accordance with two dot (..), Decode percent-encoded characters, Make percent-encoded characters uppercase, Sort query parameters by name and others.

4

Adım 4 Save the action

Add is clicked.

5

Adım 5 Edit the vService

The vService is opened with Edit.

6

Adım 6 Add the action to the Actions field

The action is selected in the Details → Actions field.

7

Adım 7 Save

Save is clicked.

Verification

1Access logBackend Service side

curl -s --path-as-is "https://www.example.com//urun//5"

ExpectedGET /urun/5 if Merge slash characters is checked

Method 5: WEB-CLI

• How it works The condition and the Remove prefix expression in Method 1 are created with WEB-CLI commands; the newPath value is the same as the expression generated by the shortcut in the interface.
• Where it is opened TR7 WEB-CLI → lb condition · lb action · lb service
• Requirement WEB-CLI access; the condition ID
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Add the condition

lb condition add criteria path query /api/ --content_placement start --name api-yolu

2

Adım 2 Get the condition ID

The action binds the condition by its ID, not by its name. lb condition add gives no output when it succeeds; the ID is seen in the id column of the condition list:

lb condition list

3

Adım 3 Add the Set Path action

lb action add type set_path name api-kirp newPath "%PATH.STRREPLACE(^/api,)" --cond <condition-id>

4

Adım 4 Check the existing actions on the vService

lb service show <vService>

The rules.0, rules.1 … lines in the output show the actions on the vService in order. --rules.N replaces the action at that position; the new action is written to the first empty position.

5

Adım 5 Add the action to the vService

If the vService has two actions (0 and 1), the new action is written to position 2; if it has no actions, --rules.0 is used:

lb service update id <vService> --rules.2 api-kirp

Verification

1Access logBackend Service side

curl -s https://www.example.com/api/v1/users

ExpectedGET /v1/users

Common Mistakes

• Assuming Set Path redirects the client. The path changes only in the request going to the Backend Service; the address on the client does not change. To send the user to another address, Location Redirection is used (How do I redirect a specific URL to another URL with a 301/302?).
• Adding Set Path without a condition. If the condition is empty, the path of all requests changes; expressions such as Remove prefix can also break paths in which the prefix is not present.
• Writing the condition as /api. A Start /api condition also captures the /apiv2/x request, and the path becomes v2/x; the condition is written with the trailing /.
• Expecting conditions based on the rewritten path. Path conditions evaluate the original form of the path in subsequent actions on the same vService and in Conditional Backend Services as well.
• Looking for verification in TR7 logs. HTTP Logs shows the address sent by the client; the rewritten path is seen in the log of the Backend Service.
• Forgetting the redirects returned by the Backend Service. If the server generates a Location header according to the new path (e.g. /v1/login), the header is corrected with Replace HTTP Header Content in On Response (Can I change a header value with a regex?).

How it is done in the documentation

• Set Path · Rewriting, Not Redirection
• Set Path · Path Operation Shortcuts
• Set Path · New Path Info
• URL Normalization · Normalization

Related questions

• What is the difference between Set Path and Set Path + Query?
• How do I redirect a specific URL to another URL with a 301/302?
• How do I route to different servers based on the URL path (e.g. /api → API servers)?