That is indeed pretty cool :-) Would the addition of a header work the way I originally suggested, though?
> On 24 Jun 2016, at 21:57, Cyril Bonté <cyril.bo...@free.fr> wrote: > > Hi all, > >> Le 24/06/2016 à 21:33, James Brown a écrit : >> +1 I am also using a fake backend with no servers and a 503 errorfile, >> and it confuses everybody who looks at the config or the metrics. Being >> able to directly emit a 429 would be fantastic. > > Interestingly, it already exists since 1.6-dev2 [1] for "http-request deny" > but the documentation is absolutely missing. And it has recently been fixed > by Willy [2]. > > Another point is that everything in the code seems to be ready to use the > same option with tarpit... except the configuration parser. > > The syntax is : > http-request deny [deny_status <code>] > > Example : > http-request deny deny_status 429 > > [1] > http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=108b1dd69d4e26312af465237487bdb855b0de60 > [2] > http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=60f01f8c89e4fb2723d5a9f2046286e699567e0b > >> >> On Fri, Jun 24, 2016 at 10:30 AM, Daniel Schneller >> <daniel.schnel...@centerdevice.com >> <mailto:daniel.schnel...@centerdevice.com>> wrote: >> >> 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 >> >> >> >> >> >> >> -- >> James Brown >> Engineer > > > -- > Cyril Bonté
