Forum Discussion

npmaslow_68104's avatar
npmaslow_68104
Historic F5 Account
Jun 25, 2009

Irule applied stream profile and URLs in comments - any thoughts?

This is more of a general TCL quesiton than an irule question, but it involves the selective application of the stream profile in an irule.

 

 

Here is the general form of the irule:

 

 

when HTTP_RESPONSE {

 

if { [HTTP::header Content-Type] starts_with "text/" }{

 

STREAM::expression

 

"@http:\u002f\u002fstuff.corp.net@https:\\u002f\\u002f

 

stuff.corp.net@"

 

STREAM::enable

 

log local0. "Streaming enabled for [HTTP::host]"

 

} else {

 

STREAM::disable

 

log local0. "Streaming NOT enabled for [HTTP::host]"

 

}

 

}

 

 

It works just fine for standard HTTP http to https stream translations, however when faced with a URL within a comment, it does not work, for example:

 

 

 

 

Are escaped text parts of an HTTP stream 'valid' to a stream profile? Thanks in advance for your thoughts.
application delivery
dev
devops
iRules

17 Replies

Sort By
Show More
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jul 31, 2009
    I'm out of ideas. If you do end up opening a support case on this, can you reply with the result?

     

     

    Thanks,

     

    Aaron
  • brad_11480's avatar
    brad_11480
    Icon for Nimbostratus rankNimbostratus
    Nov 05, 2010
    haven't seen any updates here and i see this thread is a bit dated.

     

     

    i am running v10 LTM with ASM....

     

     

    i'm running into a problem where it seems the stream expression should be replacing but it isn't. i added logging and it shows that the STREAM::enable is occuring

     

    but there is never a match (even STREAM_MATCHED) doesn't trigger.

     

    also the tcpdumps show that the data is never altered .. and it is clearly in the dump packets.

     

     

    is there something missing that is important to 'enable' the stream in addition to the irule STREAM::enable. it is almost like it is something else that is keeping it all from occuring.

     

    thanks so much...
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 05, 2010
    Hi Brad,

     

     

    I'd guess that the server is sending compressed responses. LTM won't decompress the data before applying the stream filter. If that's the case, you could either disable compression on the servers or remove the accept-encoding header from requests that you'll potentially want to rewrite the responses for.

     

     

    Aaron
  • Reddy_Gurram_95's avatar
    Reddy_Gurram_95
    Icon for Nimbostratus rankNimbostratus
    Feb 16, 2011
    This works for us...:

     

    =========_BGN_=========

     

    when HTTP_RESPONSE {

     

    Disable the stream filter by default

     

    STREAM::disable

     

     

    Check if response type is text

     

    if {[HTTP::header value Content-Type] contains "text"}{

     

     

    STREAM::expression {@http://www.example.com@https://www.example.com@}

     

     

    Enable the stream filter for this response only

     

    STREAM::enable

     

    }

     

    }

     

     

    when STREAM_MATCHED {

     

    log local0. "[IP::client_addr]:[TCP::local_port]: matched: [STREAM::match], replaced with: [string map {http:// https://} [STREAM::match]]"

     

    STREAM::replace "[string map {http:// https://} [STREAM::match]]"

     

    }

     

    =========_END_=========

     

     

    ~/Reddy Gurram

     

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 16, 2011

    Hi Reddy,

    You should actually be able to skip the STREAM_MATCHED code as you're already setting the find/replace string in the STREAM::expression command.

    Also, someone else recently pointed out that it is more complete to disable the stream filter on each request (in HTTP_REQUEST) than on every response. Using the original method, the stream filter would be left enabled for a subsequent request. ie, if there was a text response which enabled the stream filter, the stream filter would be left enabled on the subsequent HTTP request on the same TCP connection.

    Can you try this instead?

     

    
when HTTP_REQUEST {
    Disable the stream filter by default
   STREAM::disable
}
when HTTP_RESPONSE {
  
    Check if response type is text
   if {[HTTP::header value Content-Type] contains "text"}{

      STREAM::expression {@http://www.example.com@https://www.example.com@}

       Enable the stream filter for this response only
      STREAM::enable
   }
}

     

    Aaron

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Jun 12, 2018

    Just to provide a definitive answer to this issue

    STREAM::expression {@http:\\u002f\\u002fsite.net@https:\u002f\u002fsite.net@}

    works for these address specifiers.

    Note that you must use { and } to delimit the expression string (otherwise the escaping does not work correctly).

    Alternatively, you can use

    STREAM::expression "@http:\\\\u002f\\\\u002fsite.net@https:\\u002f\\u002fsite.net@"
  • Damon_Kalajzich's avatar
    Damon_Kalajzich
    Icon for Nimbostratus rankNimbostratus
    Jun 12, 2018

    I was having a similar issue and finally got it working with the following

     

    set oldstring "http:\\u002f\\u002fINTERNALSITE"

     

    set newstring "https:\u002f\u002fEXTERNALSITE"

     

    STREAM::expression "@$oldstring@$newstring@"

     

    STREAM::enable