Forum Discussion

Yossi_126945's avatar
Yossi_126945
Icon for Nimbostratus rankNimbostratus
Sep 10, 2013

Simple STREAM iRule doesn't work

Hi,

I'm trying to find/replace a string an an HTTP response body. Here is what I've done so far:

  1. Applied the default (empty value) STREAM profile to the relevant virtual-server

  2. Applied an HTTP service profile with Response Chunking set to Rechunck to the virtual-server

  3. Applied the following iRule to the virtual-server

On a packet capture I can see that 'foo' string is included in the response body but it is not replaced to 'bar' and the STREAM_MATCHED event is not triggered.

LTM version is 10.2.3 Build 112.0 Final.

Is there anything I'm missing here?

when HTTP_REQUEST {
STREAM::disable
}

when HTTP_RESPONSE {

    Check if response type is text
   if {[HTTP::header value Content-Type] contains "text"}{
      log local0. "Content-Type contains text"
       Replace foo with bar in the HTTP response body
      STREAM::expression {@foo@bar@}
       Enable the stream filter for this response only
      STREAM::enable
      log local0. "Stream enabled"
   }
}

when STREAM_MATCHED {
     log local0. "matched: [STREAM::match]"
}
application delivery
devops
iRules

8 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Sep 10, 2013

    The rule looks OK to me. Have you checked that the Content-Type header is present? Do you get any log messages? You could also add 'log local0. "No Header Match"' just before the last } of the HTTP_RESPONSE event (on it's own line) to confirm if there is no header/match.

     

  • Yossi_126945's avatar
    Yossi_126945
    Icon for Nimbostratus rankNimbostratus
    Sep 10, 2013

    both of the log lines in the HTTP_RESPONSE are executed so I know the Content-Type is present and contains "text". I did notice however in the response packet capture that the response has the following header "Content-Encoding: gzip" which suggests that the response is compressed. I'll try to remove the "Accept-Encoding" from the request and see if that's the issue.

    log local0. "Content-Type contains text"
log local0. "Stream enabled"
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Sep 10, 2013

    That'll be it, assuming it's the server doing the compression, not the F5. If it is the server, why not move it to the F5 and take some of the load off?

     

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus
    Sep 10, 2013

    Shouldn't STREAM::disable be put at the beginning of "when HTTP_RESPONSE"? And it's hard to see what's wrong without knowing what the real original/replacement strings look like.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 10, 2013

    STREAM::disable can be in the HTTP request because they're part of the same flow. I believe Steve and Yossi have discovered the problem - that the application is compressing the content, so the STREAM iRule can't see the text.

     

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus
    Sep 10, 2013

    This will prevent the backend server from returning compressed content:

    when HTTP_REQUEST_SEND {
    HTTP::header remove Accept-Encoding
}

    and hopefully will not stop the ltm from doing it; I haven't tested this, though.

  • Yossi_126945's avatar
    Yossi_126945
    Icon for Nimbostratus rankNimbostratus
    Sep 10, 2013

    Yep Jie, that's exactly what i've used. The HTTP profile should have stripped this header, but for some reason it doesn't.

     

    In any case, it works now, the compression was the issue.

     

    Many thanks What Lies Beneath for your help.