Hi Willy, Thank you for the response. It's great to know that this might be considered as a feature request in future versions, pending prioritization though.
Could you comment on why this isn't already a feature yet? It is hard to believe that we're the first to come across this draining problem when using a chain of "L4 to L7 proxies". Are there any alternative approaches that we should look at, to get around the current limitations? Thanks, Abhijeet On Sun, May 7, 2023 at 10:25 PM Willy Tarreau <w...@1wt.eu> wrote: > > 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 -- Cheers, Abhijeet (https://abhi.host)
