irule loggin a class caused all Irules using that clase to fail

Well, just looking at the line

log local0.info \"$log_line [$::valid_methods]\"

I've got a couple of questions.

First of all, why are you escaping all the double quotes? Aren't you trying to pass a string to the log command? Don't you want that string quoted?

Second, are you really trying to pass the entire contents of your class to syslog? That's what you're telling the TCL interpreter by having [$::valid_methods] in your log line. I'm not sure why you'd want to do this, as the class is a static piece of the configuration, and this would likely add a fair amount of overhead.

Colin

Colin,

 

 

Thank you for your time.

 

 

> why are you escaping all the double quotes?

 

1. The reason the quotes are backslashed is because I pulled this copy of the rule from the audit log and forgot to remove some of the back slashes for the post.

 

> are you really trying to pass the entire contents of your class to syslog

 

2. Yes, I was trying to verify what the class contained. This was for testing purposes only and and would not have remained in my final rule.

 

 

Those things aside I do not see why this completely hoarked all iRules using that class.

 

At best, it should have logged "{GET} {HEAD} {OPTIONS} {POST}" to the syslog

 

At worst, it should have caused just that iRule to fail, not all iRules using that class.

 

Even after removing that part of that iRule and doing a b load, iRules still crashed accessing that class even though b class valid_methods list showed it to be just fine????

I would guess that somehow the class value in memory was broken somehow with the logging statement using []'s. I would have expected that removing the log line and reloading the config would have fixed the problem though. If you're interested in investigating this more, you could retest it. If you're able to reproduce the problem, you could open a case with F5 support.

It looks like one issue is that you have enclosed the class name in brackets [$::valid_methods], so that the value of the class is being executed. Try replacing:

log local0.info "$log_line [$::valid_methods]"

with:

log local0.info "$log_line $::valid_methods"

You may also need to wrap the not condition in parentheses. Can you try this version?

when HTTP_REQUEST {   
   if { not ([matchclass [HTTP::method] equals $::valid_methods]) } {
      reject
   } elseif { [string tolower [HTTP::uri]] contains "cmd.exe" || [string tolower [HTTP::uri]] contains "root.exe" || [string tolower [HTTP::uri]] contains "admin.dll" } {
      discard
   } elseif { not ([HTTP::method] eq "POST") } {
      set url https://[getfield [HTTP::host] ":" 1][HTTP::uri]
      HTTP::respond 301 "Location" $url
   } else {
      log local0.info "REDIRECT_POST [IP::remote_addr] [HTTP::host] [HTTP::uri] [HTTP::header Referer] $::valid_methods"
   }
}

All of this may be moot though... if you're trying to add security to the web app by using HTTPS instead of HTTP, you would want to redirect the client to HTTPS before the POST request is made. Using the existing rule, you're redirecting the POST request after the client has already submitted the POST data unencrypted.

Also, if you redirect a POST request, the client will make a GET request to the Location header value. The client will not submit the parameters and values from the POST data in the subsequent request. You might be better off trying to redirect the previous request which the POST request is generated from, from HTTP to HTTPS.

Aaron

>If you're able to reproduce the problem, you could open a case with F5 support.

 

 

This has already been done and they are investigating. I just wanted to ping the DevCentral community as well as get any input.

 

 

>} elseif { [string tolower

 

 

I did not realize this was case sensitive. Thank you for that addition

 

 

>you would want to redirect the client to HTTPS before the POST request is made.

 

 

Thats the idea here. Theoretically, a get will always happen first, however we host pages that are under the control of other people and can't be positive that will happen. So what we are doing here is redirecting everything put posts, but logging when posts happen so that we can notify the owner of the web page that they need to fix it.