---
title: Migrating F5 iRules URI Switching to RELIANOID HTTP/S Service Matching
description: "## Overview This article explains how to migrate an F5 BIG-IP iRule that routes multiple application URIs to the same backend pool into RELIANOID using native HTTP/S farm service matching and regular expression (regex) URI patterns. The original iRule evaluates…"
url: "https://www.relianoid.com/resources/knowledge-base/troubleshooting/migrating-f5-irules-uri-switching-to-relianoid-http-s-service-matching/"
updated: "2026-05-09"
category: Troubleshooting
---

# Migrating F5 iRules URI Switching to RELIANOID HTTP/S Service Matching

## Overview

This article explains how to migrate an F5 BIG-IP iRule that routes multiple application URIs to the same backend pool into RELIANOID using native HTTP/S farm service matching and regular expression (regex) URI patterns.

The original iRule evaluates the incoming URI and sends traffic matching several application paths to the same backend pool.

## Original F5 iRule

```
when HTTP_REQUEST 
{
    switch -glob [string tolower [HTTP::uri]] 
    {
         "/firstapp*" {   
             pool "MY_POOL"  
         }

         "/secondapp*" {   
             pool "MY_POOL" 
         }

         "/thirdapp" {   
             pool "MY_POOL" 
         }
    }
}
```

## Migration Goal

The purpose of this configuration is:

- Match multiple application paths
- Route all matching traffic to the same backend pool
- Simplify application routing logic

## RELIANOID Migration Approach

In RELIANOID, this can be achieved without scripting by using:

- One single HTTP/S service
- URI pattern matching
- Regular expressions (regex)
- Shared backend configuration

This approach is simpler, cleaner, and easier to maintain than multiple conditional iRules.

## RELIANOID Configuration

Navigate to **Farms > HTTP/S Farm > Services** and **Create** a new service.

### URI Matching Configuration

In the URL pattern use the regex:

```
^/(firstapp|secondapp|thirdapp)
```

### Backends configuration

Add the backend list configuration in the service.

## Why This Approach Is Recommended

Using a single regex-based service provides:

- Cleaner configuration
- Easier maintenance
- Reduced service count
- Better scalability
- Simplified troubleshooting

Instead of managing multiple iRule conditions, the URI logic is centralized in one matching rule.

## Validation

Test with CURL. Example:

```
curl -k https://example.com/firstapp -v
```

Or:

```
curl -k https://example.com/secondapp/api/test -v
```

Expected result:

- Request is forwarded to the configured backend pool
- Application responds normally

## Troubleshooting

### Requests Not Matching

Verify:

- Regex mode is enabled
- URI pattern is correct
- No hidden spaces or invalid regex syntax

### Only Some Applications Work

Check:

- Regex includes all required application names
- URI capitalization behavior

RELIANOID regex matching is case-sensitive unless configured otherwise.

If case-insensitive matching is needed, use:

```
(?i)^/(firstapp|secondapp|thirdapp)
```

### Traffic Sent to Default Service

This usually indicates:

- Regex mismatch
- Service ordering issue
- URI normalization differences

### Alternative Approach

Although multiple services can also be created, this is generally not recommended when:

- All applications share the same backend pool
- Routing logic is identical

A single regex-based service is more efficient.

## Best Practices

- Group similar applications into shared services when possible
- Use regex carefully to avoid unintended matches
- Keep URI matching logic centralized
- Document regex rules for operational visibility

## Summary

F5 iRules performing URI-based pool selection can be migrated into RELIANOID using native HTTP/S service matching with regex patterns.

This approach simplifies configuration while maintaining equivalent application routing behavior.

### 📄 Download this document in PDF format