iRule design considerations for ISA to BigIP migration.

So on the way home from work, I was thinking about the above and it dawned on me that this might not be as hard as I first thought.

 

 

I suppose the variable elements, such as public URI and the translated application URI could live in a DGL. Using the above example - something along the lines of (pseudo code)

 

 

class myuris {

 

"/abc /xyz"

 

"/123 /789"

 

}

 

 

Then there could be an iRule on the VS which could do something along these lines (pseudo code):

 

 

rule myrule {

 

when HTTP_REQUEST

 

match HTTP URI from DGL myuris on the left

 

replace HTTP URI from DGL myuris on the right

 

}

 

 

This would mean that the iRule itself is fairly static and that the DGL is the only element that needs to be updated. I think there may be a further issue in that some URIs are /def* which maps to /uvw* so it's a case of replace the /def with /uvw but ensure that * is appended.

 

 

So the next question would be, what's the order of operation in terms of iRule vs ASM? Say I rewrite /abc to /xyz, then in my HTTP Class for ASM, would I be matching against /abc or /xyz.

 

 

I suppose I'll have to lab the above up, but first I need to work out the actual iRule syntax.

 

 

Still open to suggestions if this can be achieved any other way, but this is my (pseudo) attempt at a possible solution.

 

 

Cheers,

 

Packeteer.