I have a need to create a policy rule to process HTTP OPTIONS requests separately from other HTTP Method requests. I've noticed that on a match rule one can match on HTTP Methods but the OPTIONS method is not one that can be chosen from the list. The full selection list is default (means PUT or GET I believe), DELETE, GET, HEAD, POST and PUT. The OPTIONS method is not in the list for that matter TRACE and CONNECT are omitted as well. Interestingly when creating a count monitor an individual monitor could be created that matches on any one of the valid HTTP methods. The drop down list contains all methods including OPTIONS. I'm looking for a means to introduce a rule to filter OPTIONS request yet not have to affect (change) any other rule currently in place within my proxy. The easiest solution to me would be to have a rule first in the policy which matches on the HTTP method of OPTIONS. So my question is two fold. Short term do I have another means to filter and limit any impact to rules already in place. Herding the cats to do regression testing can be a challenge. Long term does it seem reasonable to have OPTIONS as a method that can be selected for a match rule.
I am currently on 220.127.116.11 if this has been altered on subsequent releases I would be interested to know that.
HermannSW 2700006U544742 Posts
Re: HTTP OPTIONS Method2013-01-02T22:59:36ZThis is the accepted answer. This is the accepted answer.Hi George,
the discrepancy in HTTP methods for match action (5) versus count monitors (8) does exist in 18.104.22.168 firmware, too.
Please create a PMR on this.
In the mean time, you may workaround this by
- having up to 5 rules matching for the 5 selectable methods (DELETE/GET/HEAD/POST/PUT)
- after that a match all rule for handling OPTIONS+TRACE+CONNECT
If you need distinction in last rule you may query var://service/protocol-method