Forum Discussion
Hello Joel,
Can you share one line from your iRule, the HTTP::respond function which responds with HTML content? You may replace the HTML code with a placeholder but I'd like to see if you include any headers.
- Joel_NewtonOct 19, 2016Cirrus
Hi, Hannes! I hope things are well with you. Here's the gist of the HTTP::respond:
HTTP::respond 200 content " ... ..." "Cache-Control" "no-cache, no-store, must-revalidate, max-age=0" "Edge-Control" "no-store,downstream-ttl=-1" "Pragma" "no-cache" "Expires" "-1"
- Hannes_RappOct 19, 2016Nimbostratus
Thanks for the reference. I've provided an example of my own. Such use of headers should address your problem regardless of circumstances. Some headers from your current solution are too bulky and provide no added value, but I think the real problem is the absence of Connection Close header. You want to add this to any HTTP response functions in your maintenance iRule.
HTTP::respond 200 content "html..." Cache-Control no-cache Pragma no-cache Connection Close
If after this update the issue prevails, you must do a one-time clean up of all active connections on that VS.
tmsh delete sys conn cs-server-addr YourVS-IP cs-server-port YourVS-port
Regards,
- Joel_NewtonOct 19, 2016Cirrus
Thanks, Hannes. This definitely feels like progress. I was able to get the desired behavior with the following headers:
"Cache-Control" "no-cache" "Pragma" "no-cache" "Connection" "Close" "Edge-Control" "no-store,downstream-ttl=-1"
One thing I noticed, though, was that if I used the 'event disable' command after setting the headers, and then make a 'event HTTP_REQUEST enable' call as part of the HTTP_RESPONSE, I might still see the problem. The desired behavior is that only this maintenance iRule fire and all others be disabled, but I'm thinking that doing an 'event disable' isn't the correct way. Any thoughts, or is this question scope creep? 🙂 Or does the Connection Close header preclude any other iRules from executing in the same session?
- Vijay_EOct 19, 2016Cirrus
May be try using "return", if you want to prevent further processing of the iRule.
- Joel_NewtonOct 19, 2016Cirrus
My understanding is that 'return' only prevents further processing of the iRule in question, but has no effect on the processing of other iRules attached to the same virtual server. However, I'm wondering if the combination of the maintenance iRule having a higher priority, and it closing the connection would mean that other, lower-priority iRules for that virtual server would never get executed.
- Hannes_RappOct 19, 2016Nimbostratus
You can use the 'event disable' (or even better 'event disable all' ) function after issuing the HTTP response. You're correct that this would stop further processing of all iRules for that connection whereas the 'return' function only stops further processing of the current iRule. One caveat of using 'event disable...' is that in case of conditional maintenance rules, that have let's say 'IP-address exceptions' for test/validation engineers, you could miss out on some important functionality from your other iRules while the maintenance is on-going. If there are no exceptions in your maintenance iRule, it would definitely be a great idea to use that 'event disable all' function. Also recommend to use 'priority 10' function (any number less than 500 will do).
How the end result works: The 'Connection: Close' header is a Kosher way of instructing end client and any stateful L7 middleware to tear down the existing connection after response is received, and the 'event disable all' function will give a resource-use relief to your BigIP. The 'priority 10' function which should be the 1st line in your iRule instructs the BigIP to process your maintenance iRule before the same events from any competing iRules are processed (this again is good for efficient resource use). There's no reason to use 'event enable HTTP_REQUEST' function anywhere.
Caution ('priority 10'): In regards to use of priority function in maintenance iRules, there still can be circumstances when the maintenance iRule should not be considered a top priority (first to process). To give you an example, if you have redirect iRules for mobile users, and the mobile service is not under maintenance while the main service is - then it would make sense to process those mobile-user redirects for any mobile customers, instead of responding with the maintenance page.