Forum Discussion

rolf's avatar
rolf
Icon for Cirrus rankCirrus
Sep 01, 2009

https Monitor receive string / regexp ^(caret)

Hi,

 

 

We have a interesting problem with the https Monitor.

 

We defined the send string like the following:

 

 

GET /loadbalancer.html HTTP/1.1\r\nConnection: Close\r\nHost: xxxx\r\n

 

 

When we define the receive string with a leading caret, the monitor fails:

 

^HTTP/(1.0|1.1) (200|304) OK

 

Without the leading caret, it works:

 

HTTP/(1.0|1.1) (200|304) OK

 

 

a curl output:

 

-------------------

 

> GET /loadbalancer.html HTTP/1.1

 

> User-Agent: curl/7.15.3 (i686-redhat-linux-gnu) libcurl/7.15.3 OpenSSL/0.9.7l zlib/1.1.4

 

> Host: x.x.x.x

 

> Accept: */*

 

>

 

< HTTP/1.1 200 OK

 

< Date: Tue, 01 Sep 2009 10:54:40 GMT

 

< Server: Apache

 

< Last-Modified: Thu, 13 Aug 2009 12:47:21 GMT

 

< ETag: "9526f-94-471055626c840"

 

< Accept-Ranges: bytes

 

< Content-Length: 148

 

< Connection: close

 

< Content-Type: text/html; charset=UTF-8

 

-------------------

 

 

Has anybody an idea why that happens?

 

It seams, like this phenomena just appears with https, it works with http Monitors.

 

 

We're using BIG-IP v10.0.1 (Build 354.0)

 

 

Thanks for your help,

 

Rolf
management
monitoring
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Sep 01, 2009
    Hi Rolf,

     

     

    I don't think this is the issue, but the receive string you have listed would probably fail if the server responds with a 304 as a 304 wouldn't have OK after the status code. It should be Not Modified or something similar. You might try:

     

     

    HTTP/(1.0|1.1) (200 OK|304 Not Modified)

     

     

    If it works with HTTP but not HTTPS, you could try capturing a tcpdump and make sure that the first character in the decrypted HTTP is HTTP. I expect it would be, but it would be good to double check. It sounds like this might be a bug. The monitor receive string should be applied to the decrypted response content, so theoretically, that anchor tag in the regex receive string should work for HTTPS the same as it does for HTTP.

     

     

    If you don't get a definitive answer here, you might try opening a case with F5 Support.

     

     

    Aaron
  • rolf's avatar
    rolf
    Icon for Cirrus rankCirrus
    Sep 01, 2009
    Thanks for the advice of the 304 - you're right of course. But that wasn't the cause.

     

    As I don't have the private key of the backend system it's impossible to analyze the traffic. I'll setup a test environment.

     

     

    Cheers,

     

    Rolf