One iRule Instead of a Dozen IIS Servers: Keeping Retired-Platform URLs Alive

An F5 iRule URL redirect kept published research links alive when Baylor retired one of its hosted web platforms. Ten to fifteen academic groups had published links to that platform: conference papers, research pages, institutional references. When the platform went away, those links would go with it, unless something still answered at the old hostname and sent each visitor to the new home. This post covers the mechanism: how the redirect works, how I tested it, and how the cutover ran.

The problem: links that outlive their host

Every one of those links used the old platform’s own hostname. When a hostname stops answering, every link under it fails. The content did not move to one place. Each group went to a different hosting platform, and each platform had its own layout. A single rule that maps the old name to one new name was not enough. The correct destination depended on the group and on the path.

Two plans

The web team proposed a Windows Server cluster. One administrator would own a dozen IIS instances and edit a rewrite rule for each new URL. My plan used the F5 pair we already operated: one new virtual address and one iRule.

The two plans differ in what you must maintain. The cluster spreads the work across a dozen instances. The iRule keeps the logic in one place, on a supported high-availability pair, with a small configuration and one team to run it.

My manager did not attend the meeting, so I went alone. A peer and his boss’s boss argued for the cluster. They talked over me. I stayed with the technical case, and within an hour the room chose the F5 plan.

How the F5 iRule redirect works

An iRule runs on events. The one that matters here is the HTTP request event. When a request arrives, the rule reads the Host header and the path. It then uses the HTTP::respond command to answer the browser directly with an HTTP 301 (permanent) redirect and a Location header. The request never reaches a web server.

My rule used nested conditions. The outer test checked the hostname. The inner tests checked the path to find the group, and so the destination. Some URLs also needed small path changes to fit the layout of the new hosting platform.

The sketch below shows the shape. It is a simplified illustration with placeholder names. It is not the production rule.

when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] eq "old.example.edu" } {
        switch -glob [string tolower [HTTP::path]] {
            "/group-a/*" {
                HTTP::respond 301 Location "https://a.example.edu[HTTP::uri]"
                return
            }
            "/group-b/*" {
                # Small path change to fit the new platform layout
                set new [string map {"/group-b/" "/research/"} [HTTP::uri]]
                HTTP::respond 301 Location "https://b.example.edu$new"
                return
            }
        }
    }
}

The match uses HTTP::path, which has no query string. The redirect sends HTTP::uri, which keeps it. A visitor who followed a link with a query string lands on the same query at the new address.

Why a 301

A 301 tells browsers and search engines that the move is permanent. They can cache it. That makes a wrong redirect on a real hostname slow to undo, and it is one good reason to prove the rule on a test name first.

The proof and the cutover

I created the virtual address for this project and pointed a test hostname at it. I wrote the iRule logic and ran it against real researcher URLs. A teammate who knew F5 well worked beside me on it. The nested conditions and path changes came out of that testing.

When the logic worked, I made three changes in order. First, I changed the hostname in the iRule from the test name to the real name. Second, we installed a certificate on the F5 for the real name. Third, I changed the DNS A record for the real hostname to point to the virtual address on the F5. I had edit access to live DNS, so I ran that step myself.

The certificate step is easy to miss. A browser starts a TLS handshake with the old hostname before it can receive any redirect. If the F5 does not present a valid certificate for that name, the visitor sees a certificate warning first, and the redirect never happens.

The DNS change was the only step that touched live traffic. Every step before it could be repeated at no cost to the people who used the links.

The result

About ten URL redirects went live. No IIS server needed a change. The iRule was still in production when I left.

What an F5 iRule URL redirect does not do

The redirect does not keep the old content. It also depends on two things staying in place for as long as anyone uses the old links: the old name must resolve to the F5, and the F5 must hold a valid certificate for it. Both need an owner and a renewal date. An iRule is also code, and someone must own it. I still prefer one place to maintain over a dozen, but the single place is not free.