nginx学习（十四）——lua-nginx-module，

nginx学习（十四）——lua-nginx-module，

参考地址：

https://github.com/openresty/lua-nginx-module

nginx api for lua

https://github.com/openresty/lua-nginx-module#nginx-api-for-lua

ngx.location.capture

syntax: res = ngx.location.capture(uri, options?)

context: rewrite_by_lua*, access_by_lua*, content_by_lua*

Issues a synchronous but still non-blocking Nginx Subrequest using uri.

Nginx's subrequests provide a powerful way to make non-blocking internal requests to other locations configured with disk file directory or any other nginx C modules like ngx_proxy, ngx_fastcgi, ngx_memc, ngx_postgres, ngx_drizzle, and even ngx_lua itself and etc etc etc.

Also note that subrequests just mimic the HTTP interface but there is no extra HTTP/TCP traffic nor IPC involved. Everything works internally, efficiently, on the C level.

Subrequests are completely different from HTTP 301/302 redirection (via ngx.redirect) and internal redirection (via ngx.exec).

You should always read the request body (by either calling ngx.req.read_body or configuring lua_need_request_body on) before initiating a subrequest.

This API function (as well as ngx.location.capture_multi) always buffers the whole response body of the subrequest in memory. Thus, you should use cosockets and streaming processing instead if you have to handle large subrequest responses.

Here is a basic example:

res = ngx.location.capture(uri)

Returns a Lua table with 4 slots: res.status, res.header, res.body, and res.truncated.

res.status holds the response status code for the subrequest response.

res.header holds all the response headers of the subrequest and it is a normal Lua table. For multi-value response headers, the value is a Lua (array) table that holds all the values in the order that they appear. For instance, if the subrequest response headers contain the following lines:

Set-Cookie: a=3
 Set-Cookie: foo=bar
 Set-Cookie: baz=blah

Then res.header["Set-Cookie"] will be evaluated to the table value {"a=3", "foo=bar", "baz=blah"}.

res.body holds the subrequest's response body data, which might be truncated. You always need to check the res.truncated boolean flag to see if res.body contains truncated data. The data truncation here can only be caused by those unrecoverable errors in your subrequests like the cases that the remote end aborts the connection prematurely in the middle of the response body data stream or a read timeout happens when your subrequest is receiving the response body data from the remote.