Lukas, Am 17.11.20 um 17:37 schrieb Lukas Tribus: >>> is it possible to reliably disable client keep-alive on demand based on >>> the result of an ACL? >>> >>> I was successful for HTTP/1 requests by using: >>> >>> http-after-response set-header connection close if foo >>> >>> But apparently that has no effect for HTTP/2 requests. I was unable to >>> find anything within the documentation with regard to this either. > > I don't think there is a way. In HTTP/2 you'd need to send a GOAWAY > message to close the connection. There are no instructions in the HTTP > headers regarding the connection.
I would be fine with some other method of communicating the Close / GOAWAY, e.g. using http-response stop-serving-this-client. > I *think/hope* we are actually sending GOAWAY messages when: > > - some timeouts are reached > - hard-stop-after triggers > - a "shutdown session ..." is triggered > > > You could check if sending a "421 Misdirected Request" error to the > client could achieve your goal, but it certainly behaves differently > than a close in H1 (you can't get a successful answer to the client). > It's also a workaround. It will not. What I was attempting to do was forcing clients to re-establish the TCP connection after every request when rate limits are exceeded to slow them down and / or spend more resources. The reason is that we want to avoid outright blocking with e.g. a 429 Too Many Requests, because that could affect legitimate traffic. Forcing the client to re-establish the connection should not be noticeable for a properly implemented client, other than an increased latency. I'm aware that this will be more costly for us as well, but we have plenty of spare capacity at the load balancers. > Triggering GOAWAY/full H2 connection teardown dynamically would need > to be implemented. I think in HTX all connection headers are > immediately dropped (they are not "translated" and applied to the > connection). > Can you (or anyone else) comment on whether that would actually be feasible? I would create a feature request in the tracker then. If not I'll save the effort. If I can get some pointers I might even have a stab at implementing this myself. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 [email protected] www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P
