Christopher, Am 19.11.20 um 11:47 schrieb Christopher Faulet: > Le 19/11/2020 à 10:49, Tim Düsterhus, WoltLab GmbH a écrit : >> John, >> >> Am 19.11.20 um 06:57 schrieb John Lauro: >>> A couple of possible options... >>> You could use tcp-request inspect-delay to delay the response a >>> number of >>> seconds (and accept it quick if legitimate traffic). >> >> I believe the tcp-(request|response) rules only apply to the very first >> buffer of a single TCP connection and thus do not apply here. Let me >> give an example of what I want to do. >> > > Tim, > > tcp-(request|response) content rules are evaluated on all HTTP > transactions. tcp-request connection/session rules are only evaluated on > the client connection establishment.
Oh, indeed and it's even documented. I just applied my knowledge about `mode tcp` without checking. I never had a use for tcp-request content rules for HTTP traffic, the http rules are simply much better. > However, this does not help you, because in H2, adding a delay on a > stream will not stop the traffic for other streams on the same connection. And even for H1 it would not help much for my use case, because having a connection sit idle for a few seconds still allows a rogue client to pay the TLS cost only once per connection, just increasing the number of connections required by a constant factor instead of linearly increasing the number of connections. > Thanks for the feature request. > Do you have a first estimation whether this would require intimate knowledge of the architecture and larger changes to implement? If it's a matter of adding a flag somewhere and a few lines checking that flag after handling the response then I might attempt it 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
