Forum Discussion

Moe_Jartin's avatar
Oct 06, 2011

FYI: Disabling HTTP processing for non-HTTP traffic

I know there are several code samples and discussions on this topic but, I wanted to add this for others who might run into the same problem. Not sure where else to post this.

 

 

Note: This problem was specific to a Java applet but this irule would work for any non-HTTP app tunneled over HTTP.

 

 

We had a problem with an application that called a Java applet on an HTTP VIP. I finally realized that I just needed to disable the HTTP parser using HTTP::disable. So i used this modified version of an iRule I found on DevCentral:

 

 


when CLIENT_ACCEPTED {
    Enable HTTP processing for all requests by default
   HTTP::enable
}
when HTTP_REQUEST {
   selectively disable HTTP processing for specific URIs
  switch -glob [string tolower [HTTP::uri]] {
    /javauri1* -
    /javauri2* { 
      HTTP::disable
    }
  }
}

 

 

However, this did not resolve the issue. There were a couple of other iRules associated to the VIP which also called the HTTP_REQUEST event. Apparently, even though I had called the HTTP::disable command, the HTTP_REQUEST event in the other irules "re-enabled" the HTTP parser???? So i modified the irule a bit to run the HTTP_REQUEST event in this iRule first and disable the event if the URIs in question were called.

 

 


when CLIENT_ACCEPTED {
    Enable HTTP parser for all requests by default
  HTTP::enable
}

 set priority higher for HTTP_REQUEST event so this iRule runs first (default is 500)
when HTTP_REQUEST priority 100 {
    Selectively disable HTTP parser for specific URIs
  switch -glob [string tolower [HTTP::uri]] {
    /javauri1* -
    /javauri2* {
      HTTP::disable
        Disable HTTP_REQUEST event for this connection
        so that other iRules cannot not call HTTP parser
      event disable
    }
  }
}

 

 

Joe M

 

 

 

 

 

3 Replies

  • I know there are several code samples and discussions on this topic but, I wanted to add this for others who might run into the same problem. Not sure where else to post this.

     

    Note: This problem was specific to a Java applet but this irule would work for any non-HTTP app tunneled over HTTP.

     

    We had a problem with an application that called a Java applet on an HTTP VIP. I finally realized that I just needed to disable the HTTP parser using HTTP::disable. So i used this modified version of an iRule I found on DevCentral:

     

    when CLIENT_ACCEPTED {

     

    Enable HTTP processing for all requests by default

     

    HTTP::enable

     

    }

     

    when HTTP_REQUEST {

     

    selectively disable HTTP processing for specific URIs

     

    switch -glob [string tolower [HTTP::uri]] {

     

    /javauri1* -

     

    /javauri2* {

     

    HTTP::disable

     

    }

     

    }

     

    }

     

    However, this did not resolve the issue. There were a couple of other iRules associated to the VIP which also called the HTTP_REQUEST event. Apparently, even though I had called the HTTP::disable command, the HTTP_REQUEST event in the other irules "re-enabled" the HTTP parser???? So i modified the irule a bit to run the HTTP_REQUEST event in this iRule first and disable the event if the URIs in question were called.

     

    when CLIENT_ACCEPTED {

     

    Enable HTTP parser for all requests by default

     

    HTTP::enable

     

    }

     

    set priority higher for HTTP_REQUEST event so this iRule runs first (default is 500)

     

    when HTTP_REQUEST priority 100 {

     

    Selectively disable HTTP parser for specific URIs

     

    switch -glob [string tolower [HTTP::uri]] {

     

    /javauri1* -

     

    /javauri2* {

     

    HTTP::disable

     

    Disable HTTP_REQUEST event for this connection

     

    so that other iRules cannot not call HTTP parser

     

    event disable

     

    }

     

    }

     

    }

     

     

  • Interesting ... Good solution, thanks.

     

     

    Not sure I understand the use case though.

     

     

    Are you saying the HTTP profile was messing up the java applet code as it flowed through tunneled under the HTTP protocol? Or did the initial GET/POST then just open a TCP stream that was not HTTP at all and totally unique to that applet communication flow? Curious why the approach was taken ... Is the virtual also supporting other HTTP traffic and this is a special case under a more general VIP?

     

     

    Just trying to understand applicability. Thx