Forum Discussion

schusb's avatar
schusb
Icon for Nimbostratus rankNimbostratus
Dec 18, 2018

<http_request> - ERR_NOT_SUPPORTED (line 2) invoked from within "HTTP::query"</http_request>

We've running an iRule on v13.1.0.6 which works fine. After upgrading to v14.1.0 the same iRule causes an error:

err tmm[11570]: 01220001:3: TCL error: /Common/test_ir_asm_error-page  - ERR_NOT_SUPPORTED (line 2)     invoked from within "HTTP::query"

Here's the responsible part of the iRule:

when HTTP_REQUEST
{
set mainPath "show-error-page"
set mainPathExists "FALSE"

set httpQuery [HTTP::query]
set httpUri [HTTP::uri]
set httpUrlMin [call ir_asm_library::getMinimalizedUrl]

if {$httpUri contains $mainPath}
{
    set mainPathExists "TRUE"
    set iFileErrorPageName [URI::query [HTTP::uri] "page"]
}
}

Why we can't call [HTTP:query] , [HTTP:uri] or [HTTP:host] within a HTTP_REQUEST event anymore?

UPDATE:

We already solved the problem. This issue was caused by another iRule which is attached to the same vServer (executed before) and uses HTTP::respond in order to answer with a css-file used by the asm error page.

The following iRule

when HTTP_REQUEST
{
    switch -glob [string tolower [HTTP::uri]] {
        "/css/if_css_e.css" {HTTP::respond 200 content [ifile get if_asm_css_e] "Content-Type" "text/css" }
        "/css/if_css_e_ext.css" {HTTP::respond 200 content [ifile get if_asm_css_e_ext] "Content-Type" "text/css" }
        "/css/if_css_ee.css" {HTTP::respond 200 content [ifile get if_asm_css_ee] "Content-Type" "text/css" }
    }
}

was replaced by:

when HTTP_REQUEST
{
    switch -glob [string tolower [HTTP::uri]] {
        "/css/if_css_e.css" {HTTP::respond 200 content [ifile get if_asm_css_e] "Content-Type" "text/css"
        "Connection" "Close"
         event disable all }
        "/css/if_css_e_ext.css" {HTTP::respond 200 content [ifile get if_asm_css_e_ext] "Content-Type" "text/css"
        "Connection" "Close"
         event disable all }
        "/css/if_css_ee.css" {HTTP::respond 200 content [ifile get if_asm_css_ee] "Content-Type" "text/css"
        "Connection" "Close"
         event disable all }
    }
}

Is this a bug in v14.1 or a bug in in the iRule which was tolerated by v13.1.0.6 and v14.0.0 ?

ASM Advanced WAF
iRules
security
  • PeteWhite's avatar
    PeteWhite
    Icon for Employee rankEmployee
    Dec 27, 2018

    I suspect that they have improved the error handling related to multiple iRules - not a bug per se.

     

  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Dec 27, 2018

    You may not evaluate HTTP request after you execute a HTTP::respond or HTTP::redirect... F5 only enforced this in new versions.

     

    In version 14.0, F5 introduced a new command to prevent this issue : HTTP::has_responded

     

    try this code to leave the irule if another one made this one invalid.

     

    when HTTP_REQUEST {
  if {[HTTP::has_responded]} {return}
  set mainPath "show-error-page"
  set mainPathExists "FALSE"
 
  set httpQuery [HTTP::query]
  set httpUri [HTTP::uri]
  set httpUrlMin [call ir_asm_library::getMinimalizedUrl]
 
  if {$httpUri contains $mainPath}
  {
      set mainPathExists "TRUE"
      set iFileErrorPageName [URI::query [HTTP::uri] "page"]
  }
}

     

    • Nick_T1's avatar
      Nick_T1
      Icon for Nimbostratus rankNimbostratus
      May 22, 2019

      Using "event disable all" followed by "return" is no longer sufficient under v14.1? Only the `HTTP::has_responded` method?

       

      I was previously accomplishing this behavior by putting those two commands in any iRule where I sent a response, but maybe there is a separate issue (like I need to do a log before the redirect first?)

  • Mark_Burrows's avatar
    Mark_Burrows
    Icon for Nimbostratus rankNimbostratus
    May 09, 2019

    The problem I have here is that a simple http redirect to https causes the above "issue"

     

  • Nick_T1's avatar
    Nick_T1
    Icon for Nimbostratus rankNimbostratus
    Aug 19, 2019

    For the future, it was the final statement. I had logging statements which previously worked but were broken by the upgrade to v14. I corrected this in the standby unit for testing and my "event disable all > return" technique continues to work.

     

    Strangely, I do not have HTTP::has_responded available to me (at least in the editor showing syntax) in 14.0 or 14.1, so I'll have to check with support about that.

Related Content