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
<[email protected]
<mailto:[email protected]>> 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é
