Forum Discussion

hooleylist's avatar
hooleylist
Icon for Cirrostratus rankCirrostratus
Sep 21, 2009

Effect of 'drop/discard' in HTTP_RESPONSE event?

Hi,

 

 

I'm wondering what drop/discard actually do when called from HTTP_RESPONSE. I don't have an easy way to test the customer's exact scenario, so I'm hoping someone here can tell me what it *should* do.

 

 

Ideally, I'd like to just not send that specific HTTP response back to the client, but leave the server side TCP connection available for further OneConnect use.

 

 

If I check a status code in HTTP_RESPONSE, see it's one I don't like, and call 'drop' or 'discard', does it just prevent the current payload from being sent to the client?

 

 

Does it affect any further data that the server might send for that response or in subsequent responses to other HTTP requests?

 

 

Does it trigger a FIN or RST being sent on the serverside connection? Does this behavior change if OneConnect is enabled on the VIP?

 

 

As long as I'm asking about 'drop/discard', would 'reject' behave differently in terms of the serverside TCP connection being left open?

 

 

Thanks,

 

Aaron
application delivery
dev
devops
iRules

13 Replies

Sort By
Show More
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Aug 31, 2010
    Oh, I misunderstood. You said an HTTP Post, not a reply. Sorry.

     

     

    In that case, though, how would the BIG-IP know what client the server is giving a response for?
  • Yepher_100160's avatar
    Yepher_100160
    Icon for Nimbostratus rankNimbostratus
    Aug 31, 2010
    I am thinking in the "when HTTP_REQUEST {}" from the client it would store a reference to the clients connection.

     

     

    When the second server does the POST it would pass that reference as a query param or maybe an HTTP header value. The F5 would then rewrite the post body as an HTTP Response to the originating client.

     

     

     

  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Sep 02, 2010
    Since your second server is connecting to the BIG-IP, it's really more of a client, and there's no automatic way to hook two clients together like that. The only solution I can see is to do something like: 
     This is on your main VIP that your clients talk to
when HTTP_RESPONSE {
  set resp ""
  while { $resp == "" } {
    after 100
    set resp [table lookup $clientkey]
  }
  HTTP::respond $resp
}
     This is on a different VIP that your "second servers" send their "requests" to
when HTTP_REQUEST {
  set clientkey [HTTP::header X-ClientKey]
  table set $clientkey "HTTP/1.0 200 OK\r\n\r\n[HTTP::header X-Client-Data]"
  HTTP::respond "HTTP/1.0 200 OK\r\n\r\n"
}
    This is just for illustrative/explanatory purposes; I haven't checked this code at all. It's not very efficient, and of questionable scalability, but likely the best you can do. You should test it out to see if it can meet your capacity needs. Hope this helps!