On Fri, May 05, 2023 at 04:18:25PM -0700, Abhijeet Rastogi wrote:
> Thanks for the response Tristan.
>
> For the future reader of this thread, a feature request was created
> for this. https://github.com/haproxy/haproxy/issues/2146
I've looked again at the code and am seeing that in modern versions
(2.8) we can provoke a soft-stop of a connection by just calling
sc_must_kill_conn() which will set SE_FL_KILL_CONN on the stream
endpoint. This is only performed by the "reject" action in the
http_action_reject() function.
We could imagine having an action that sets this; it would also need to
support the after-response rules so that it can easily be centralized.
We'll need to test it to make sure it doesn't kill connections a bit
too fast.
Another approach would be to reuse "connection: close" for this, which
would make sure that the same method already used on h1 also works on
newer protocols. I'm just thinking that the risk to introduce side
effects by accident is probably not worth it, compared to the low cost
of having a specific action to say "notify the peer that we're going
to close ASAP". There are at least 2/3 levels of active close though:
- notify the client we'd like to stop (GOAWAY(2^31-1)) : the client
will close by itself when it wants, but knows we'd prefer to use
a new connection. That's the best one for reloads or migrations
since there's zero impact.
- notify the client that the last received stream is the last one
and that other ones will be discarded (GOAWAY(last_id)): this
forces the client to resend new requests that might be in flight.
- close immediately (typically upon an attack or so). That's normally
used by rejects, though it will still cause active requests to be
completed, so in practice it might be the same as the previous one.
This will require more experiment, but maybe we could do something
like this for 2.8 (but as usual the devil is in the details).
Willy
