使用 nc 果然可以直观的见到 internal 的访问;
不过根据文档,ngx.location.capture 中 uri 形式主要3种:
- ngx.location.capture('/foo/bar?a=3&b=4')
- ngx.location.capture('/foo?',{ args = 'b=3&c=%3a' } })
- ngx.location.capture("/foo",
{ args = { cmd = 'incr', key = ngx.var.uri } }
)
但是,要使用对, agentzh 提及的技巧有点遗漏,反馈一下:
配合的 nginx 配置:
resolver 114.114.114.114;
location = /pish {
internal ;
proxy_pass http://127.0.0.1:1974/phish/?$arg_query ;
}
- 这里的 $arg_query 是标准的 nginx 内置参数表达,意思是:
- 每次请求中全局性的GET 模式中 query=XXX 形式给出的值
即:
如果 lua 中进行的捕获是以下任何形式:
local Q = "sina.com"
local TT = "1332228869.315"
getURL = "q=sina.com×tamp=1332228869.315"
ngx.location.capture("/pish?" .. getURL)
ngx.location.capture('/pish?',{ args = tostring(getURL)})
ngx.location.capture("/pish"
,{arg={ q=Q
,timestamp=TT
}}
)
都将实际访问了无参数的内部地址 /pish?
所以,通用的方法是:
resolver 114.114.114.114;
location = /pish {
internal ;
proxy_pass http://127.0.0.1:1974/phish/?$args ;
}
- $args 是 GET 时,所有参数的完整字串!
attemp to use a non-string key in the "args" option table,
在 2012年3月16日 下午6:49，agentzh <age...@gmail.com> 写道：
> On Fri, Mar 16, 2012 at 6:35 PM, Zoom.Quiet <zoom...@gmail.com> wrote:
>>
>> - 这真心明白,只是怎么可以观察到 proxy_pass 真实进行请求的 url ?
>> - 以便明确lua 的处理是否正确?
>
> 有两种方法：
>
> 一是使用 nc 工具。比如在本地用下面的命令启动 nc 以监听 1978 端口：
>
> nc -l 1978
>
> （有的系统会需要使用命令 nc -l -p 1978）,然后临时修改你的 nginx 配置以便让 proxy_pass 指向它：
>
> proxy_pass http://127.0.0.1:1978/phish/?$args
>
> 重新加载 nginx 配置后如从前那般请求你的接口，然后在启动 nc 的终端检查 ngx_proxy 发送的原始的 HTTP 请求。
>
> 2. 重新编译 nginx 以启用 Nginx 调试日志，然后在 nginx 配置文件中使用 debug 日志级别。然后正常请求你的接口，在 Nginx
> 的 error.log 文件中应当会看到类似下面这样的 dump:
>
> [debug] 20844#0: *1 http proxy header:
> "GET /foo?blah HTTP/1.0^M
> Host: 127.0.0.1:1987^M
> Connection: close^M
> ^M
> "
>
> 当然，使用 tcpdump 之类的抓包工具来搞也是可以的。
>
> Regards,
> -agentzh
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/
