Hello! We use haproxy as an L7 rate limiter based on tracking certain header fields and URLs. A more detailed description of what we do can be found in a blog post I wrote about this some time ago:
https://blog.codecentric.de/en/2014/12/haproxy-http-header-rate-limiting Our exact setup has changed a bit since then, but the gist remains the same: * Calculate the rate of requests by tracking those with identical authorization header values * If they exceed a threshold, slow the client down (tarpit) and ask them to come back after a certain period by sending them HTTP 429: HTTP/1.1 429 Too Many Requests Cache-Control: no-cache Connection: close Content-Type: text/plain Retry-After: 60 Too Many Requests (HAP429). I am currently refactoring our haproxy config to make it more readable and maintainable; while doing so, I would like to get rid of the somewhat crude pseudo backend in which I specify the errorfile for status code 500, replacing 500 with 429 when sending it out to the client. This, of course, leads to the status code being 500 the logs and other inconveniences. My suggestion about how to handle this would be an extension to the "http-request deny" directive. Currently it will always respond with HTTP status code 403. If there were a configuration setting allowing me to specify different code (like 429 in my case) as the reason for the rejection, that would be an elegant solution. Using an "http-request set-header" would even allow me to specify different values for the "Retry-After:" header to inform well-written clients after which time they should come back and try again. Does that sound like a sensible addition? Cheers, Daniel -- Daniel Schneller Principal Cloud Engineer CenterDevice GmbH https://www.centerdevice.de
