For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

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

5 Replies

  • 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