reject¶
Description¶
Causes the connection to be rejected, returning a reset as appropriate
for the protocol. Subsequent code in the current event in the current
iRule or other iRules on the VS are still executed prior to the reset
being sent.
If the VS is using FastHTTP, reject commands will not work, at least
under 11.3.0.
Syntax¶
reject
reject¶
- Causes the connection to be rejected, returning a reset as appropriate for the protocol. In the case of TCP, the client will receive a TCP segment with the RST bit set. In the case of UDP, an ICMP unreachable message will be generated.
- The system connection table entry associated with the flow is also removed.
- Subsequent code in the current event is still executed prior to the reset being sent. If there are other iRules with the same event, those event(s) will also be executed. See the second example below for details.
Examples¶
when CLIENT_ACCEPTED {
if { [TCP::local_port] != 443 }{
reject
}
}
Example showing how code in a second iRule in the same event will
still execute after reject is called
# Rule 1 on VS1
when HTTP_REQUEST priority 100 {
# This event in this iRule runs first
reject
log local0. "Rejecting this request"
}
# Rule 2 on VS1
when HTTP_REQUEST priority 200 {
# This event in this iRule runs second
log local0. "This will still execute"
}
Example showing how code in a second iRule in the same event can be
prevented from executing after reject is called
# Rule 1 on VS1
when HTTP_REQUEST priority 100 {
# This event in this iRule runs first
reject
log local0. "rejected"
# Disable future events in this or any other iRule on the virtual server
event disable all
# Exit this event of this iRule immediately
return
# This never gets executed
log local0. "not hit"
}
# Rule 2 on VS1
when HTTP_REQUEST priority 200 {
# This event in this iRule runs second but won't be executed
log local0. "This will still execute"
}