Get request_body in set_by_lua directive

[agentzh]

On Mon, Mar 19, 2012 at 6:02 PM, rishabh <nginx-forum at nginx.us> wrote:
>
> Another concern is, Say the processing time of LUA file is 10 seconds
> and the request completes in 4 seconds. So will the total time NGINX
> take will be 10 secs or 14 secs ?
>
>
> Here is how i have structured my conf
>
> http {
>
>       server {
>
>              location / {
>                     proxy_pass http://upstream123;
>                     post_action @loglua;
>              }
>
>              location @loglua {
>                     set $log '';
>                     rewrite_by_lua_file /nginx/mylua.lua;
>                     logformat format1 '$log';
>                     access_log /var/log/nginx/newlog.log format1;
>              }
>       }
> }
>

I don't think this question is really related to the ngx_lua module.
This is really a question about the behavior of the standard
"post_action" configure directive.

The answer can be trivially found out by preparing a small example:

    location /test {
        echo_sleep 1;
        post_action @post;
    }

    location @post {
        echo_sleep 5;
    }

Here we use ngx_echo module's echo_sleep directive to do non-blocking
sleep to emulate the time of real processing and computation.

By using the "curl" utility to access the /test interface defined
above, we can only observe a delay of 1 sec:

    $ time curl localhost:8080/test
    real	0m1.009s
    user	0m0.004s
    sys	0m0.005s

But we can not really draw a conclusion from just this because "curl"
actively closes the connection as soon as when it sees the end of the
response (in this case, the "last chunk" sent from nginx). But nginx
will not really close the connection until the post_action thing
completes, as can be seen when we use telnet to do the HTTP request
outself:

    $ telnet 127.0.0.1 8080
    GET /test HTTP/1.1
    Host: localhost
    Connection: close

    0

The "last chunk", i.e., the "0\r\n\r\n" bytes, appears right after 1
sec's delay but the current telnet session does not quit until another
5 sec is passed. That is, the nginx does not close the current
connection until 5 + 1 == 6 sec is passed.

If HTTP keepalive is enabled, the extra delay can make the second
request on the same connection much slower. But if HTTP keepalive is
disabled, we're probably safe because most decent HTTP clients will
actively close the connection even if Nginx does not do that on the
server side.

Regards,
-agentzh