Thanks!<br><br><div class="gmail_quote">On Sat, Jul 7, 2012 at 8:19 PM, agentzh <span dir="ltr"><<a href="mailto:agentzh@gmail.com" target="_blank">agentzh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<div class="im"><br>
On Sat, Jul 7, 2012 at 4:41 PM, Mike Gagnon <<a href="mailto:mikegagnon@gmail.com">mikegagnon@gmail.com</a>> wrote:<br>
> I have the impression that $request_body isn't available until the<br>
> content-handlers phase. Is that correct?<br>
><br>
<br>
</div>It depends on actual nginx modules. It's the nginx module's<br>
responsibility to trigger request body reading (or discarding). For<br>
ngx_proxy, ngx_fastcgi, and many other upstream modules, they run in<br>
the content phase, so request body is read in that phase.<br>
<br>
But in modules like ngx_form_input, it reads the request body at<br>
rewrite phase, see<br>
<br>
    <a href="https://github.com/calio/form-input-nginx-module" target="_blank">https://github.com/calio/form-input-nginx-module</a><br>
<br></blockquote><div><br></div><div>Thanks for the pointer! I just looked at the source for form-input-nginx-module.</div><div><br></div><div>It gives me the impression that the function ngx_http_read_client_request_body() isn't guaranteed to read the complete request_body before it is time to find the value for a set_form_input variable. In other words. it seems possible that the directive "set_form_input $data" might not work if the request_body isn't fully read before ngx_http_set_form_input() is called.</div>
<div><br></div><div>I gathered this impression because it looks like ctx->done is only set after request_body is fully read. However, the function ngx_http_set_form_input() only advances to the function ngx_http_form_input_arg() if ctx->done is set.</div>
<div><br></div><div>Do you know of my analysis correct?</div><div><br></div><div>I would like to ensure that the request_body is fully read before my module attempts to read it during the rewrite phase.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And in ngx_lua, we can read request body at various phases at our own<br>
will, like "rewrite", "access", and "content" phases.<br>
<div class="im"><br>
> Is it possible to hack nginx such that the rewrite phase is delayed until<br>
> after the request_body is available? I am writing a module that analyzes<br>
> requests during the rewrite phase to determine where to route them. The goal<br>
> is to use online machine learning to detect suspicious requests and re-route<br>
> them to a quarantine. <a href="http://mikegagnon.com/2012/06/08/beer-garden/" target="_blank">http://mikegagnon.com/2012/06/08/beer-garden/</a><br>
><br>
<br>
</div>We're just using ngx_lua to do suspicious request filtering in rewrite<br>
and/or access phases. It's convenient (and also rather efficient) to<br>
use the various Lua APIs for Nginx provided by ngx_lua. See<br>
<br>
    <a href="http://wiki.nginx.org/HttpLuaModule" target="_blank">http://wiki.nginx.org/HttpLuaModule</a><br>
<br>
It even supports streaming reading of request body via the "downstream<br>
cosocket" API, so you can implement "input body filter" in pure Lua.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Thanks for the Lua tips. Lua has a reputation for speed, but I am worried it won't be as performant as a well engineered C module. Normally, I wouldn't be concerned with minor speed improvements but I am specifically trying building my module to withstand CPU overload attacks. Within my context, it is critical that my module be able to classify incoming requests quickly.</div>
<div><br></div><div>Do you think I am under-estimating Lua's performance capability?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

> If I have access to the request_body during the rewrite phase then my<br>
> request classifier will be better at detecting suspicious requests (since it<br>
> has more information about requests).<br>
><br>
<br>
</div>It's more appropriate to do that at the access phase, preferably<br>
running after the nginx "access" phase. (You can just ngx_lua's<br>
access_by_lua or access_by_lua_file directives.)<br>
<br></blockquote><div><br></div><div>Thanks for the tip!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Best regards,<br>
-agentzh<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div><br>