I found a way to mitigate it, if anyone interested.

At first, I thought that trying to rate-limit would not provide results, as
the JS callback could still retry, not caring about the returned code.
It seems sending 503 after rate limiting (not having allowed any queue with
the 'burst' parameter) is enough.
---
*B. R.*

On Thu, Apr 2, 2015 at 11:41 AM, B.R. <reallfqq-nginx@yahoo.fr> wrote:

> Hello,
>
> I am facing a problem on a website which has been using AJAX callbacks to
> report JS errors.
> It seems there has been sth wrong going on and a tremendous number of
> errors are being reported through the callback.
> You could say the website owner crafted it own DDoS vector.
>
> Errors collection has been deactivated and our cache purged so new
> visitors are unaffected.
> However it seems an old version of the cache is stored somewhere in a
> specific network since its gateway is responsible for a huge amount of
> requests.
>
> The question is:
> - Knowing the current version of the page is OK
> - Knowing we isolated the callback calls (POST, not cached) in nginx to
> alleviate the pain previously inflicted to the backends
>
> Is there a way (HTTP Status code?) to tell the page making these callbacks
> to refreh itself?
>
> I was thinking about 205, but I am unsure if it means what I think it
> does. Does it merely clear forms and other types of user input in the page?
> For now, We are serving 204, even though the JS script does not seem to
> like it (requests volume increased, but nginx can handle without problem of
> course).
> ​The problem is now traffic volume...​
> ---
> *B. R.*
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx