Multiple passes to memcached with different keys

Merlin merlin at mahalo.com
Wed Mar 25 05:29:16 MSK 2009


Atif,

You will most likely need to use the error_page directive to fallback to an
internal location.  Something like what I have below should be work-able.
Disclaimer: I have not tested this, and I do not know how the memcached
module works (it may reconnect to the memcached server for each check,
lowering performance).

location / {
  error_page 404 = @site;
  set $memcached_key /lock/$remote_addr;
  memcached_pass 10.10.10.1:11211;
}

location @site {
  internal;
  error_page 404 = @app;
  set $memcached_key /lock/$host;
  memcached_pass 10.10.10.1:11211;
}

location @app {
  ... whatever you normally pass to...
}

- Merlin

On Tue, Mar 24, 2009 at 6:26 PM, Atif Ghaffar <atif.ghaffar at gmail.com>wrote:

> Hi all,
>
> I would like to test 2 memcached keys before passing to the content.
>
> Background:
> Our CMS app has DDOS protection that can lock and IP ($remote_addr) or the
> complete website ($host)
>
> For example if an IP is misbehaving then there is a key like /lock/
> 192.168.123.123  (DOS protection)
> If this key is present then I just want to return the value of the key
> "Sorry. too many requests from your IP, etc"
>
> This is fine.
>
> location / {
>  set $memcached_key /lock/$remote_addr;
>  memcached_pass 10.10.10.1:11211;
>  ...
>  do something with the request
> }
>
> The second scenario is that a fleet of machines are attacking a single
> website (DDOS) then there will a lock such as
> /lock/mysite.com
>
> So my question is: Is it possible to check both keys such as
>
> location / {
>   set $memcached_key /lock/$remote_addr;
>  memcached_pass 10.10.10.1:11211;
>
>  set $memcached_key /lock/$hostr;
>  memcached_pass 10.10.10.1:11211;
>
> ...
>  do something with the request
> }
>
>
>
>
>
> --
> best regards
> Atif Ghaffar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090324/5250d9ed/attachment.html>


More information about the nginx mailing list