aFleX Troubleshooting

The aFleX scripting language is based on the Tool Command Language (Tcl) programming standard. Here are some popular aFleX misconfigurations.




aFleX syntax error message “wrong # args: no script following”

Note: aFleX syntax errors are displayed in the WebUI when you save the aFleX script (Config > Service > aFleX) or in the CLI (aflex check script-name).

This type of error is usually on an “if” line. In Tcl language, the opening curly bracket (" { ") has to be on the same line as the closing curly bracket. A space is required between the curly brackets: "} {"

Good:    if { [HTTP::uri] starts_with "/private")} {
xyz
}


Bad:       if { [HTTP::uri] starts_with "/private")}
{
xyz
}


Bad:   if { [HTTP::uri] starts_with "/private")}{
xyz

}




aFleX execution abort errors – wrong variable name

Note: aFleX execution abort error statistics are available in the WebUI (Monitor > Service > aFleX) and in the CLI (show aflex script-name).

This type of error can be caused by a variable name that has a dash (" - ") in it. aFleX variables can contain numbers, letters and underscore ( _ ).

Good:   set ip_addr "10.0.0.10"
Bad:      set ip-addr "10.0.0.10"




aFleX execution abort errors – HTTP header not present

This type of error can occur when the aFleX script tries to read an HTTP variable that does not exist in the request or the response. For instance, response HTTP header “Location” is not always present. Typically, this header is present only in server redirects (response code 301 or 302).

Good:    if { [HTTP::header exists "Location"]} {
if {[HTTP::header Location] contains "intranet.example.com"} {
xyz
}


Bad:       if { [HTTP::header Location] contains "intranet.example.com"} {
xyz
}





aFleX HTTP content rewrite not done There is no aFleX error or failure but the HTTP content in the response is not modified.

This error can occur if servers reply with compressed content. To prevent servers from replying with compressed content, remove the request header “Accept-Encoding”, so the servers will believe that clients do not support compression.

Note: You can always configure HTTP compression to occur on the AX device itself to improve end-user response time.

Good:      when HTTP_REQUEST {
HTTP::header remove Accept-Encoding
}
when HTTP_RESPONSE {
HTTP::collect
}
when HTTP_RESPONSE_DATA {
xyz
HTTP::release
}


Bad:       when HTTP_RESPONSE {
HTTP::collect
}
when HTTP_RESPONSE_DATA {
xyz
HTTP::release }
Tags:

Add new comment