Forum Discussion

krisnaseechurn's avatar
krisnaseechurn
Icon for Altostratus rankAltostratus
Jul 19, 2022

Error: read ECONNRESET error while using Postman for API calls after change to irule

Am getting connection resets after modifying irule. Error is below:

TCL error: /Common/irule_172.29.8.1 <HTTP_RESPONSE> - can't use non-numeric string as operand of "&&" while executing "if { [HTTP::status] == "404" && {![HTTP::header] contains "Content-Type:application/json" && ![HTTP::header] contains "Content-Type:application/xml" &..."

The extract from the irule is below.

if { [HTTP::status] starts_with "4" && {[HTTP::header] contains "Content-Type:application/json" || [HTTP::header] contains "Content-Type:application/xml" || [HTTP::header] contains "Content-Type:application/problem+json"} } {
set irule "Irule_Catch_404"
set http_status [HTTP::status]
set res_start_time [clock format [clock seconds] -format "%Y/%m/%d %H:%M:%S"]
set req_elapsed_time [expr {[clock clicks -milliseconds] - $tcp_start_time}]
if { [HTTP::header exists "Content-Length"] } {
set req_length [HTTP::header "Content-Length"]
} else {
set req_length 0
}

there is no syntax error as I can save the changes but F5 logs show that connection is being reset

 

  • StephanManthey's avatar
    StephanManthey
    Aug 15, 2022

    Hi krisnaseechurn, the HTTP::redirect command is used a couple of times in your iRule.

    It´s best practice, to use a "return" command afterwards and perhaps an "event disable" command to prevent the iRule from further execution.

    Personally I´m trying to avoid the HTTP::redirect. Instead I prefer to use HTTP::respond because it´s providing very granular control about the exact status code (maybe you prefer a 301 instead of 302?). It also allows to add a Connection Close header. Along with an "event disable" command followed by a "return" you will definitely avoid further execution of the iRule event where the command was fired.

    For debugging it would help to force an unwanted redirect and monitor the /var/log/ltm for log entries and TCL errors/warnings:

    tail -f /var/log/ltm

     

  • krisnaseechurn's avatar
    krisnaseechurn
    Aug 16, 2022

    thanks for all the input..

    the issue was it was missing an !

    if { !([HTTP::status]=="500") && \

  • Hi krisnaseechurn,

    Can you use parentheses( ) instead of braces{ } in if condition?

     

    when HTTP_RESPONSE {
    	if { [HTTP::status] == 404 && ([HTTP::header] contains "Content-Type:application/json" || [HTTP::header] contains "Content-Type:application/xml" || [HTTP::header] contains "Content-Type:application/problem+json") } {
    		set irule "Irule_Catch_404"
    ...

     

     

     

  • This one is working without errors:

    when CLIENT_ACCEPTED {
      set tcp_start_time [clock clicks -milliseconds]
    }
    when HTTP_RESPONSE {
      if { ([HTTP::status] starts_with "4") && \
           ([HTTP::header Content-Type] contains "application/json" || \
            [HTTP::header Content-Type] contains "application/xml" || \
            [HTTP::header Content-Type] contains "application/problem+json") } {
        set irule "Irule_Catch_404"
        set http_status [HTTP::status]
        set resp_start_time [clock format [clock seconds] -format "%Y/%m/%d %H:%M:%S"]
        set resp_elapsed_time [expr {[clock clicks -milliseconds] - $tcp_start_time}]
        if { [HTTP::header exists "Content-Length"] } {
          set resp_length [HTTP::header "Content-Length"]
        }
      } else {
        set resp_length 0
      }
      log local0. "$resp_length; $resp_elapsed_time"
    }

     

     

    • krisnaseechurn's avatar
      krisnaseechurn
      Icon for Altostratus rankAltostratus

      hi, the solution works but partly :(. F5 is now happy with the syntax however it is still triggering a 302. 

      (Editors Note: the remainder of this post has been redacted by request. The solution was not part of this content.)

      • StephanManthey's avatar
        StephanManthey
        Icon for MVP rankMVP

        Hi krisnaseechurn, the HTTP::redirect command is used a couple of times in your iRule.

        It´s best practice, to use a "return" command afterwards and perhaps an "event disable" command to prevent the iRule from further execution.

        Personally I´m trying to avoid the HTTP::redirect. Instead I prefer to use HTTP::respond because it´s providing very granular control about the exact status code (maybe you prefer a 301 instead of 302?). It also allows to add a Connection Close header. Along with an "event disable" command followed by a "return" you will definitely avoid further execution of the iRule event where the command was fired.

        For debugging it would help to force an unwanted redirect and monitor the /var/log/ltm for log entries and TCL errors/warnings:

        tail -f /var/log/ltm