求助，如何根据 upstream server 返回的头部对最终给用户返回的头部进行修改？

[huang jun wen]

大家好，

我刚刚接触 openresty，希望用它来实现这样的功能：

1. 从客户端到 openresty 的请求头中获取一个 token，查询 redis 获得它对应的内容，将此内容设置到另一个头部，接着此请求交给 upstream server 去做实际处理；这部分可以在 access_by_lua* 这个钩子完成

2. 从 upstream server 完成后，可能会设置一个头部，这部分内容需要写入 redis，生成并返回一个 token 给客户端；我一开始觉得应该是在 header_filter_by_lua* 这个钩子里完成这个任务，但我看到 lua-resty-redis 文档里有这段话

• This library cannot be used in code contexts like init_by_lua*, set_by_lua*, log_by_lua*, and header_filter_by_lua* where the ngx_lua cosocket API is not available.

那么这样的功能该如何实现呢？

[Kwanhur Huang]

hello，

考虑使用subrequest+upstream的方式，得到响应内容后即可进一步处理

Kwanhur Huang

TL;DR

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty...@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

[gmailLee]

直接全部用 lua-resty-http。走cosocket发送请求

发自我的 iPhone

--

[huang jun wen]

谢谢回复，可否详细说明一下如何发起 subrequest 吗？

在 2017年11月2日星期四 UTC+8下午8:30:06，Kwanhur Huang写道：

[huang jun wen]

谢谢回复，这个看上去挺不错，不知道性能上会有多大的损耗呢？是否有生产环境是这样使用的？

在 2017年11月2日星期四 UTC+8下午9:56:10，李凌写道：

[Zhang Chao]

ngx_lua 的子请求会把所有的 body 缓存在内存里，所以如果 body 太大就不太适合了

[tokers]

如果 content 阶段由 ngx_lua 来接管，灵活性会高很多，结合 balancer_by_lua 效果更佳。

相关的 http 库：

https://github.com/pintsized/lua-resty-http

https://github.com/timebug/lua-resty-httpipe

[huang jun wen]

谢谢回复，我研究一下～

在 2017年11月3日星期五 UTC+8上午10:22:47，tokers写道：

[Kwanhur Huang]

hello，

若子请求body大且频繁，比如图片请求等场景，subrequest+proxy_cache的方式会比lua-resty-http更合适

根据具体应用场景选择，综合权衡较好些

Kwanhur Huang

TL;DR

[雷钦]

On 2017-11-03 23:58:30 +0800, Kwanhur Huang wrote:
> hello，
>
> 若子请求body大且频繁，比如图片请求等场景，subrequest+proxy_cache的方式会比lua-resty-http更合适
>
> 根据具体应用场景选择，综合权衡较好些

根据文档 subrequest 会把 body 全部读入内存

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.

而 lua-resty-http 则可以用流处理

The body_reader iterator can be used to stream the response body in
chunk sizes of your choosing, as follows:

如果子请求body大且频繁，感觉还是用 lua-resty-http 更合适。如果需要 cache
, lua-resty-http 也可以 +proxy_cache

[huang jun wen]

对，感觉 lua-resty-http 更适合一般性的 proxy

在 2017年11月4日星期六 UTC+8下午3:15:58，雷钦写道：

[永夜]

 lua-resty-http 也可以 +proxy_cache   不行吧，　没启用Proxy_pass 是没法启用proxy_cache的吧 ？

------------------ 原始邮件 ------------------

发件人: "huang jun wen"<kass...@gmail.com>;

发送时间: 2017年11月5日(星期天) 上午10:16

收件人: "openresty"<open...@googlegroups.com>;

主题: Re: [openresty] 求助，如何根据 upstream server 返回的头部对最终给用户返回的头部进行修改？

[雷钦]

On 2017-11-06 09:57:34 +0800, 永夜 wrote:
> lua-resty-http 也可以 +proxy_cache 不行吧，　没启用Proxy_pass 是没法启用proxy_cache的吧 ？

更 ngx.location.capture 类似， lua-restry-http 可以请求一个 openresty
内部的 server，再由这个 server proxy_pass 到 upstream 就能用 proxy_cache
了。不过 ngx.location.capture 是在程序内部处理的，只是不能用流处理；
lua-retry-http 则需要经过本地网卡，性能上会有所损失，但是可以用流处理。
如何取舍还是要看具体情况。

[dat...@openresty.com]

你好！

可以在 header_filter_by_lua  或者 log_by_lua 里读取 header，然后使用 ngx.timer.at(0) 来写 redis。