iRules: How to avoid HTTP_RESPONSE from rule 2 affect rule 1

So you don't want the HTTP_RESPONSE event to get triggered (based on some criteria I presume)?

At a minimum you could do something like this in your HTTP_REQUEST event:

event HTTP_RESPONSE disable

So it would look something like below? I will give it a try. 

rule 1:

when HTTP_REQUEST {
 if { [HTTP::path] contains "did725"} {
  pool mypool 
 }
}
event HTTP_RESPONSE disable

rule 2:
 
when HTTP_REQUEST { 
 if { [HTTP::path] contains "did825"} {
}
when HTTP_RESPONSE priority 501 {
 if { [HTTP::status] == 200 } {
    HTTP::header insert name value  
 }
}

I have to assume you're simplifying the iRules for forum consumption, but I would point out one very important aspect of "stacking" iRules. When you apply multiple iRules to a single VIP, and those iRules have the same events in them, the compiler will mesh all of the same events together. So in your example, the compiled iRule might look something like this:

when HTTP_REQUEST {
    if { [HTTP::path] contains "did725"} {
        pool mypool 
    }
    if { [HTTP::path] contains "did825"} { 
         ...doing nothing...
    }
}
when HTTP_RESPONSE priority 501 {
    if { [HTTP::status] == 200 } {
        HTTP::header insert name value  
    }
}

So if you think about in this way, and given what (I believe) your requirement is, it may be easier to use a single iRule and adjust the syntax accordingly:

when HTTP_REQUEST {
    if { [HTTP::path] contains "did725"} {
        pool mypool 
    } elseif { [HTTP::path] contains "did825" } {
        set hdr_insert
    }
}
when HTTP_RESPONSE {
    if { ( [info exists hdr_insert] ) and ( [HTTP::status] == 200 ) } {
        unset hdr_insert
        HTTP::header insert name value  
    }
}

Kevin,

That makes sense. Alright, I will give it a shot.

Thanks much!