Forum Discussion

Saul_Andres_Riv's avatar
Saul_Andres_Riv
Icon for Altostratus rankAltostratus
Jan 14, 2021
Solved

HTTPS health monitor with POST TMOS 13

Hello.

I am trying to configure the following POST monitor but it is not working.

 

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

ltm monitor https MON_HTTPS_TEST {

  adaptive disabled

  defaults-from https

  destination *:*

  interval 5

  ip-dscp 0

  recv "HTTP/1.1 200 OK"

  recv-disable none

  send "POST /web-e/AutenticationFi HTTP/1.1\r\nHost: test.example.com\r\nAccept: */*\r\nContent-Length: 431\r\nContent-Type: application/xml;charset=ISO8859-1\r\n\r\n <TCFX> <HeaderRq TRNUID=\"830709062778379\" SESSCOOKIE=\"7cf5b287-9cc4-4fa2-af87-dbd3461c9e4d\" BANKID=\"0015\" APPID=\"AW0718001\" DATECREATED=\"2021/01/08 05:03:26\" CLIENTIP=\"190.66.208.17\" CONTRACTTYPE=\"SVEPLUS\" CUSTOMERTYPE=\"FS003\" CUSTOMERID=\"2020092901\" USERTYPE=\"FS003\" USERID=\"2020092901\" USERNAME=\"2020092901\" LANG=\"ES\" CHN=\"002\" SCHN=\"2\" UNIQUEID=\"830709062778379\"/> <SumyRq SUMYTYPE=\"ALLACCOUNTS\" SUMYTIME=\"REAL\"></SumyRq></TCFX>"

  time-until-up 0

  timeout 16

}

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

 

If I perform the cURL it gives me the expected response successful

 

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

curl -vk -X POST https://test.example.com/web-e/AutenticationFi -H Content-Type: 'application/xml;charset=ISO8859-1' -d '<TCFX> <HeaderRq TRNUID="830709062778379" SESSCOOKIE="7cf5b287-9cc4-4fa2-af87-dbd3461c9e4d" BANKID="0015" APPID="AW0718001" DATECREATED="2021/01/08 05:03:26" CLIENTIP="190.66.208.17" CONTRACTTYPE="SVEPLUS" CUSTOMERTYPE="FS003" CUSTOMERID="2020092901" USERTYPE="FS003" USERID="2020092901" USERNAME="2020092901" LANG="ES" CHN="002" SCHN="2" UNIQUEID="830709062778379"/> <SumyRq SUMYTYPE="ALLACCOUNTS" SUMYTIME="REAL"></SumyRq></TCFX>'

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

 

 

ANSWER

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

> POST /web-e/AutenticationFi HTTP/1.1

> Host: test.example.com

> User-Agent: curl/7.47.1

> Accept: */*

> Content-Length: 431

>

* upload completely sent off: 431 out of 431 bytes

< HTTP/1.1 200 OK

< X-Powered-By: Servlet/3.1

< Content-Language: en-US

< Date: Thu, 14 Jan 2021 15:45:41 GMT

< Transfer-Encoding: chunked

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

 

 

Any idea why the health monitor is not working?

Thanks a lot

application delivery
BIG-IP
LTM
monitor
  • Saul_Andres_Riv's avatar
    Saul_Andres_Riv
    Feb 15, 2021

    Hi,  

    Thanks for your help.

    It was not necessary to apply an external monitor (which I was concerned about a reported vulnerability)

     

    With F5 Support, the following could be validated:

    ***************************************************

    "HTTP monitors with POST typically fail when the Content-Length header is incorrect, which makes the receiving side parser out of sync with the sender - I can see a hint of why it was miscounted.

    The command line:

    -H Content-Type: 'application/xml;charset=ISO8859-1' -d '<TCFX> <HeaderRq TRNUID=....

    Indicates the post data (-d) is starting directly with the < character, however, in the configuration, and in the logs, there's still an extra space:

    Content-Type: application/xml;charset=ISO8859-1\

    \

     <TCFX> <HeaderRq ...

    ^???

    This space is also visible in the logs:

    [0][13255] 2021-01-14 10:29:33.071367: ID 1151 :(_send_active_service_ping): writing ....xml; charset=ISO8859-1\x0d\x0a\x0d\x0a <TCFX> <He

                                    ^???

    The (successful) POST seem to be indeed 431 bytes long, however, the monitor as configured seem to contain an additional space making the body 432 bytes long"

    ***************************************************

     

    So, I just removed the extra space before <TCFX> and it worked

5 Replies

Sort By
  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for MVP rankMVP
    Jan 15, 2021

    Mmm interesting,,, well your conversion seems to be properly done, wherever required, special chars have been escaped. I could think of 2 possibilities, please test it and tell us or turn on logging & check it.

     

    1. If the content length is not matching, the requests would not work as expected. Try without this.
    2. Try removing this header Content-Type: 'application/xml;charset=ISO8859-1' & test it with a simple -H "Content-Type: application/json", i dont know if the semi-colon is also considered as a special char (after xml & before charset) & requires to be escaped.

     

    So give it a shot.

  • Saul_Andres_Riv's avatar
    Saul_Andres_Riv
    Icon for Altostratus rankAltostratus
    Jan 15, 2021

    Hi,  

    Thanks for your reply

     

    I did what you suggested but it was not successful.

    1. First, I removed the Content-Length
    2. Second, I changed the Content-Type

    The monitor continues to mark the pool down

    • jaikumar_f5's avatar
      jaikumar_f5
      Icon for MVP rankMVP
      Jan 20, 2021

      As a temp solution, you can go with external monitor, use the same curl cmd & capture the output.

      Put an if condition to see if it matches the result & then echo Up.

  • Saul_Andres_Riv's avatar
    Saul_Andres_Riv
    Icon for Altostratus rankAltostratus
    Feb 15, 2021

    Hi,  

    Thanks for your help.

    It was not necessary to apply an external monitor (which I was concerned about a reported vulnerability)

     

    With F5 Support, the following could be validated:

    ***************************************************

    "HTTP monitors with POST typically fail when the Content-Length header is incorrect, which makes the receiving side parser out of sync with the sender - I can see a hint of why it was miscounted.

    The command line:

    -H Content-Type: 'application/xml;charset=ISO8859-1' -d '<TCFX> <HeaderRq TRNUID=....

    Indicates the post data (-d) is starting directly with the < character, however, in the configuration, and in the logs, there's still an extra space:

    Content-Type: application/xml;charset=ISO8859-1\

    \

     <TCFX> <HeaderRq ...

    ^???

    This space is also visible in the logs:

    [0][13255] 2021-01-14 10:29:33.071367: ID 1151 :(_send_active_service_ping): writing ....xml; charset=ISO8859-1\x0d\x0a\x0d\x0a <TCFX> <He

                                    ^???

    The (successful) POST seem to be indeed 431 bytes long, however, the monitor as configured seem to contain an additional space making the body 432 bytes long"

    ***************************************************

     

    So, I just removed the extra space before <TCFX> and it worked

  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for MVP rankMVP
    Feb 19, 2021

     

     

    Thats great to hear its resolved. I knew it would be something on content length 🙂

    Can you mark your answer as solution.