Forum Discussion
NiHo_202842
Cirrostratus
CirrostratusWhat to do after HTTP::respond ?
Hello,
I currently have a maintenance-unavailable iRule that returns a HTML page when the vs is in maintenance mode (value in datagroup list) or is not available. (LB_FAILED)
My first check is if...
Hannes_Rapp
Nimbostratus
NimbostratusConnection Close header instructs customer's browser to close the old TCP connection. It's much more kosher than just bluntly doing TCP::close which will only tear down the connection in BigIP, but not in customer's browser. Also note that you will never need to use TCP::close and Connection Close in the same conditional routine. The return function has no functional value in your use-cases, but it does no harm to keep it for readability (some admins might prefer). The event disable all function can be safely replaced by just event disable.
I've adjusted one of your conditional routines. That's how you can provide the same functions while using less lines of code.
if { [HTTP::uri] eq "/bip-company-logo.gif" }{
HTTP::respond 200 content [ifile get "company-logo"] noserver Content-Type image/gif Connection Close
event disable
}
- Hannes_Rapp
As a general rule, a LTM Local Traffic Policy should be preferred over iRule for performance reasons (see Kai's post here: https://devcentral.f5.com/questions/advantages-of-local-traffic-policies-vs-irules). In case of maintenance iRules/Policies, instead of serving all the static content from BigIP, I'd recommend issuing a 302 temp redirect to a specialized splash/maintenance service that is managed by the application owners, not middleware admins.
- Hannes_Rapp
No, you don't need to use return to stop iRule processing. It serves no use.
'event disable' stops processing of the event (HTTP_REQUEST) in this, and all other iRules attached to VS. Unlike with 'event disable all', it does not stop processing of other events in this, or any other iRule.
- Hannes_Rapp
Hello Kai,
Yes, it's a quite nasty iRule indeed. I used to do similar iRules for maintenance a few years ago. Now I realize F5 doesn't need to be a dumpster of HTML pages and static images just because the functionality is there. It's best to just collaborate with apps team to migrate any maintenance HTML and static content to Apache/NIX (or better yet, CDN).
If he could do the above, moving to a Local Traffic policy will no longer be that difficult. I do agree with you that iRules are still needed. They even took some LTM policy functionality out since v12, instead of adding any new :(
- Kai_Wilke
MVP
@NiHo: You're welcome and have a nice weekend too!
@Hannes: I'm fine with your decission to redirect the stuff to somewhere else. But keep in mind that is has still certain benefits to keep the browsers on-site and display a temporary errorpages as needed. Hell yeah, it cost some CPU cycles, but in the end its worth every cent...
Cheers, Kai
- Hannes_Rapp
Never expected I'd be able to shaken your belief in iRule solutions :)
Apart from perf, there's another point. If you use complex iRules, you will need to hire guys who have proficiency in iRules, i.e. Kai Wilke. That will rob you a lot of cents. If you use basic iRules, you can cope with your "Cisco CCNA" guys who will work for a warm lunch.
- Kai_Wilke
Hi Hannes,
If you want to safe additional money, then take a look to Kemp Loadbalancers. They can pretty much compete with pure LTM Policies ;-)
But you're right, even the Gartner Group has pointed out that:
- F5 has a very deep set of functionalities, but many customers do not fully leverage the platform's capabilities. (Source: Gartner Report)
... but if you want to leverage them and even hire external consultants...
- F5's APIs, scripting and integration capabilities often result in a series of lock-in features for F5 customers. (Source: Gartner Report)
... I will be most likely get a lock-in too. But I'm very glad that at least my customers telling me that I'm worth every cent they spent... ;-)
Cheers, Kai
