Le 2/6/23 à 12:08, William Dauchy a écrit :
Hi Christopher,
On Fri, Feb 3, 2023 at 7:59 PM William Dauchy <wdau...@gmail.com> wrote:
On Tue, Oct 18, 2022 at 4:15 PM Christopher Faulet <cfau...@haproxy.com> wrote:
On all HTX versions, K/A and close modes are handled in the H1 multiplexer.
Thus, on these versions, http_reply_and_close() is only closing the stream. The
multiplexer is responsible to close the client connection or not.
On pre-HTX versions, when http_reply_and_close() is used, the client connection
is also closed. It is a limitation of of HAProxy versions using the legacy HTTP.
Note there is a case where the connection client may be closed. If the HAProxy
response is returned before the end of the request, the client connection is
closed. There is no (not yet) draining mode at the mux level.
coming back on this very late:
`http-request wait-for-body time` or a `http-request tarpit` mitigate
the draining issue?
I am trying to find a workaround on a setup where we are behind
another L7 LB where we unexpectedly close the connection.
> saying another way, what is going the behaviour of `http-request
return` if I have:
http-request wait-for-body time 1s if CONDITION_A
http-request deny if CONDITION_A
Is it going to wait for the request, and so mitigate the mentioned
drain limitation we currently have in the mux when `CONDITION_A`
matches?
Hi William,
The tarpit action is final. So it cannot be used in addition to a return or a
deny action. For the wait-for-body action, indeed, it will wait for the body or
a full buffer for 1 second. Thus in this case, if the whole request can be
stored in buffer and is received fast enough, this will mitigate your issue.
FYI, we are refactoring the way errors, aborts and shutdowns are handled
internally. And the data draining at the mux level is definitely a subject we
should address. It is a painful work but we hope to include it in the 2.8, at
least partially.
--
Christopher Faulet