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

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