Forum Discussion

ottleydamian's avatar
ottleydamian
Icon for Cirrus rankCirrus
Mar 03, 2019

TCP iRule to find HTTP headers

I have a situation where I have an iRule that works once the user is using the HTTP protocol. Unfortunately, the same VIP handles a proprietary protocol from Oracle called T3. To use the iRule I need an HTTP profile but that will break the T3 users.

 

  • My idea is the parse the TCP and determine if the request is HTTP
  • If it is HTTP, add an HTTP profile and my iRule to the VIP dynamically

I would like some help. I know the a TCP header is 20 bytes and HTTP starts with the method GET or POST. So I am guessing that I have to 'scan' the tcp payload for a GET (for example) and if it starts with that, apply the http profile and then the iRule.

 

Thanks for your help and/or guidance in advance!

 

application delivery
iRules
LTM
  • Niels_van_Sluis's avatar
    Niels_van_Sluis
    Mar 03, 2019

    I think you could limit the iRule to this:

    when CLIENT_ACCEPTED {
    HTTP::disable
    TCP::collect 4
}

when CLIENT_DATA {
    if { [TCP::payload 4] contains "GET" } {
        HTTP::enable
    }
    TCP::release
}

when HTTP_REQUEST {
    my irule
}

when HTTP_RESPONSE {
    my irule
}

    I'll expect the HTTP_REQUEST and HTTP_RESPONSE events will not be triggered when the HTTP profile is disabled.

  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Mar 05, 2019

    lgtm, only change I'd make is to assure all the request methods supported by your http app are accounted for in your conditional.

     

  • ottleydamian's avatar
    ottleydamian
    Icon for Cirrus rankCirrus
    Mar 03, 2019

    My first thoughts are something like this: (the HTTP profile will be configured on the VIP)

     

    ` when CLIENT_ACCEPTED { TCP::collect 4 } `

     

    ` when CLIENT_DATA { if { ([TCP::payload 4] contains "GET") || ([TCP::payload 4] contains "POST") } { HTTP::enable How to add the iRule??? } else { HTTP::disable How to remove the iRule??? } TCP::release } `

     

  • ottleydamian's avatar
    ottleydamian
    Icon for Cirrus rankCirrus
    Mar 03, 2019

    Another thought I had was disabling and enabling events so I can have 1 iRule: (I haven't tested it in production yet but my preliminary test suggest that it should work)

    when CLIENT_ACCEPTED {
  TCP::collect 4
}
when CLIENT_DATA {

log local0. "Before GET"

  if { [TCP::payload 4] contains "GET" } {
     HTTP::enable
     event HTTP_REQUEST enable
     event HTTP_RESPONSE enable
     rule Levi-Test

log local0. "After GET"  
     if { [PROFILE::exists http] == 1 }{
     log local0. "HTTP profile was added"
     }
    } else {
    HTTP::disable
    event HTTP_REQUEST disable
    event HTTP_RESPONSE disable
    rule none
    log local0. "HTTP profile was removed..."
}
 TCP::release
}
when HTTP_REQUEST {
my irule
}
when HTTP_RESPONSE {
my irule
}
  • Niels_van_Sluis's avatar
    Niels_van_Sluis
    Icon for MVP rankMVP
    Mar 03, 2019

    I think you could limit the iRule to this:

    when CLIENT_ACCEPTED {
    HTTP::disable
    TCP::collect 4
}

when CLIENT_DATA {
    if { [TCP::payload 4] contains "GET" } {
        HTTP::enable
    }
    TCP::release
}

when HTTP_REQUEST {
    my irule
}

when HTTP_RESPONSE {
    my irule
}

    I'll expect the HTTP_REQUEST and HTTP_RESPONSE events will not be triggered when the HTTP profile is disabled.

  • ottleydamian's avatar
    ottleydamian
    Icon for Cirrus rankCirrus
    Mar 05, 2019

    Thanks,

     

    My iRule has both GET and POST.

     

    if { ([TCP::payload 4] contains "GET") || ([TCP::payload 4] contains "POST") } {

     

    Thanks guys for all your great help (Niels van Sluis & Jason Rahm). I'm very positive that this will work once I get to implement it.