Am 25.04.2016 um 18:10 schrieb Craig McLure:
>From a firewall perspective all sockets are configured to forcefully
stop after about 20 minutes after which time a connection will go
'stale' and no longer function, any additional packets on that socket
will be ignored.
And why would you configure the firewall to do this? I don't see how this
makes
sense.
Resource limitations, physical restrictions, upstream limitations,
security requirements, could be anything, it's not really relevant to
the discussion, there could be many reasons why someone needed a
specific cut-off after a certain amount of time.
Explaining your use-case would be useful so we could suggest
alternatives, or
by understand the actual use-case, consider an implementation.
Clearly you are not interested in that.
This is true if you make assumptions about what's happening on the
backend, 10 minutes was (as noted) an example, could be 3 hours, could
be 200 years, the relevance here was simply existence of the
functionality. As far as connections dropped during in-flight request
/ response cycle, they should follow the HTTP spec on how to behave in
that scenario, and obviously the 'force close' would occur prior to
the firewall dropping the connection.
Its not an assumption, because value of the timeout is, as you are
saying, irrelevant.
You are saying force closing the session in the middle of a response
leading to
a truncate response and forcing the client to do the request all over
again is
something you would consider for your production environment?
With that in mind, it's not overly uncommon behaviour. nginx for
example has keepalive_timeout to facilitate the behaviour I'm looking
for here
I think your understanding of what nginx does is flawed.
First of all nginx won't drop an active session (while a response is in
flight), so
unless all of those responses are very short-lived and all clients are
fast, the
transaction may endure long enough to hit your firewall thresholds.
The other thing is just because the server transmits a FIN, doesn't mean the
client can't send another request.
What I'm saying is, you cannot guarantee on the HTTP level that a session
will be closed after a certain amount of time.
You can give the browser and the server some hints, sure. But a hint is
all it is (what nginx does).
Lukas
