Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1
Fixed In:
13.0.0, 12.1.2
Opened: Apr 06, 2016 Severity: 4-Minor
'ICAP::method' iRule function is documented as 'ICAP::method <REQMOD|RESPMOD>' which is said to get as well as set (modify) the ICAP method type in the ICAP_REQUEST event. Validation has at times rejected an argument, and at times accepted it. In fact the argument is ignored even if validation accepts it: the method type cannot be changed by the iRule. When validation rejects it, the system posts an error similar to the following: 01070151:3: Rule [/Common/icap_test] error: /Common/icap_test:2: error: [unexpected extra argument "REQMOD"][ICAP::method "REQMOD"]
Users may attempt to change the method type. Usually the validator rejects it. In some versions the validator accepts it, but the methods only return the existing method type.
iRule in ICAP_REQUEST event with 'ICAP::method REQMOD' or 'ICAP::method RESPMOD'.
Do not attempt to change the method type with 'ICAP::method <method>'.
ICAP::method is now documented as simply 'ICAP::method' with no argument, and it simply returns the current method type 'REQMOD' or 'RESPMOD'.