Hi Thibault,

I just started to do filtering POST spam in nginx. As a base I took form-input-nginx-module to get POST and GETs from there. There is no big deal to get requests.
I'm going to link to external spam filter. And for now there is big qestion is how much filtering posts will slow down hole nginx server. As I understand you are going to do something
similar so we can sync efforts. It also would be great to take a look at working code.

Thanks,
Eric.

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Oct 2010 11:41:39 +0200
> From: Thibault Koechlin
> To: nginx-devel@nginx.org
> Subject: Question about arguments from a GET/POST request
> Message-ID: <1288086099.2649.116.camel@zeroed.int.nbs-system.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I have started to write a module which goal is to act in a similar way
> to "mod_security" in Apache. To keep it short, it will provide
> applicative filtering, denying some requests if the module think they
> are evil or contains specific attack signatures. Nginx will be used as a
> reverse proxy here.
>
> So far, I've managed to make a really basic module (based on
> ngx_http_access_module) that is able to allow or deny a request
> according to various (extremely simple) pattern matching. I have now to
> parse the uri, args and post data, to start the "real stuff". When I say
> "parse", I mean being able to cut down every argument (POST or GET), in
> order to be able to run regexp (or things like that) on both value and
> variable name. So this brings me to my question :
> - Is there, inside the ngx_http_request_t structure (or somewhere else),
> a "parsed" version of get/post args ?
> - If not, is there any module that is actually performing this kind of
> operation ?
>
>
>
> PS: I've looked to the "ngx_http_variable_value_t *variables;" in the
> ngx_http_request struct, but it doesn't seem to be that ... On the other
> hand, some folks on the channel told me that the python interface is
> able to access those vars, so they must be somewhere ! ;)
>
> Best regards,
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://nginx.org/mailman/listinfo/nginx-devel
>
>
> End of nginx-devel Digest, Vol 12, Issue 15
> *******************************************
>
>

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel