Thank you very much. That will be a good opportunity to work with the Lua
functionality. As the value for the retry-after header should be variable for
different situations, the error file would not help; but for simple scenarios
it will be perfectly fine, leaving the right information in the logs and being
nice and readable :-)
> On 24 Jun 2016, at 23:13, Cyril Bonté <cyril.bo...@free.fr> wrote:
>
>> Le 24/06/2016 à 22:57, Daniel Schneller a écrit :
>> That is indeed pretty cool :-)
>> Would the addition of a header work the way I originally suggested, though?
>
> Only by adding an errorfile for 429 status.
> Or you can play with lua !
> For example :
> http-request use-service lua.shaping if <any condition you want>
>
> and the lua service :
> core.register_service("shaping", "http", function(applet)
> applet:set_status(429)
> applet:add_header("Content-Type", "text/plain")
> applet:add_header("Retry-After", "60")
> applet:start_response()
> applet:send("Please come back later")
> end )
>
>
>>
>>> 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é
>
>
> --
> Cyril Bonté
