Forum Discussion
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
- dragonflymrCirrostratus
Sorry, I was to fast. Actually situation is like that:
when SERVER_CONNECTED { Some test, when failed reject TCP::close }
Above disables sending
contentHTTP::response
When
is removed thenTCP::close
is send.HTTP::response
Why
executed at serverside disables sending HTTP response on clientside?TCP::close
Piotr
- KT_271103Nimbostratus
For what scenario you are applying above irule ? Please explain your scenario.
- dragonflymrCirrostratus
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
- KT_271103Nimbostratus
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.
- dragonflymrCirrostratus
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
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com