Forum Discussion
What to do after HTTP::respond ?
Connection 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
}
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 :(
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com