Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
Dec 01, 2017

SERVER_CONNECTED and reject - how affects clientside

Hi,

 

From my test when I use reject in SERVER_CONNECTED event then following sequence of events is triggered (hope that logging indicates order of events):

 

  • LB_FAILED
  • CLIENT_CLOSED
  • SERVER_CLOSED

I have HTTP::respond in LB_FAILED but it's not executed. What is the reason? In LB_FAILED clientside connection should be still open so iRule should be able to send response - but looks like it is not the case.

 

Is reject in SERVER_CONNECTED somehow removing/disabling clientside TCP connection?

 

If it is so is there any way to send HTTP response instead of TCP connection reset sequence?

 

Piotr

 

5 Replies

  • Sorry, I was to fast. Actually situation is like that:

    when SERVER_CONNECTED {
        Some test, when failed
        reject
        TCP::close
    }
    

    Above disables sending

    HTTP::response
    content

    When

    TCP::close
    is removed then
    HTTP::response
    is send.

    Why

    TCP::close
    executed at serverside disables sending HTTP response on clientside?

    Piotr

  • For what scenario you are applying above irule ? Please explain your scenario.

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus

      That is part of my rewrite of ProxyPass iRule so quite a log story... to make it short I need:

       

      • Check if VS has Server SSL profile attached
      • If so check if Server SSL profile configured via Data Group or generated based on naming convention exists.

      Both above test can be earliest (or I am wrong here) performed in SERVER_CONNECTED event.

       

      If both above test fail I would like to send 500 error to connecting client and reset serverside and clientside connections.

       

      Right now it seems that using only reject in SERVER_CONNECT works OK - LB_FAILED is triggered and HTTP::respond command executed - so seems my goal is achieved.

       

      If so I am curious why sequence (in SERVER_CONNECTED):

       

      • reject
      • TCP::close

      triggers LB_FAILED but HTTP::respond is not executed.

       

      Piotr

       

  • Client initiate the URL and destined to F5 and as per your comments if "Server SSL profile not available in corresponding VS" thereafter sending reset packet to server and client from F5 by using reject command, in this scenario no need worry about HTTP::respond. And hope can ignore LB_FAILED, TCP::close.

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus

      Because this is all about HTTP communication and being a bit more polite for client using browser, I do not like to just generate TCP session reset - I would like to inform client about some issues with accessed site via HTTP response codes.

       

      Second reason is that when TCP connection is reset/closed browser is trying to send request few times in a row - at least Firefox seems so. This is overhead so I would like to avoid it. When instead of TCP reset 403 or 500 is returned browser is not trying to send more request.

       

      Piotr