nginx：对proxy_pass响应头执行操作

Question

我想使用nginx作为前端代理，但是根据响应的MIME类型（Content-Type标头），它会有条件地代理另一个URL。

例如，假设有1％的客户使用的是不处理PNG的用户代理。对于那个UA，如果响应的类型是image / png，我想再次将proxy_pass转换为一个特殊的URL，它将获取PNG并将其转换为我。

理想情况下，我会这样做而不会损害99％不需要这种特殊处理的用户的性能和缓存。我无法修改后端应用程序。 （否则我可以让它检测到UA并修复响应，或发送X-Accel-Redirect来让nginx运行另一个位置块。）

如果这不可能或性能不佳，我会在哪里开始编写模块以达到预期的效果？因为，哪个扩展点让我最接近实现这个逻辑？

编辑：似乎我可以使用Lua执行子请求，然后检查那里的响应头。但这意味着通过Lua传递每个请求似乎不是最理想的

Answer 1

虽然我确信可以有正当理由去做你想做的事，但你的实际image/png示例并不像它看起来那么简单。浏览器不再在image/png HTTP请求标头中包含Accept，就像他们以前在png是新的时候一样，所以，你必须拥有整个检测和映射表。非常古老的浏览器。

此外，从架构的角度来看，你想要实现的目标还不是很清楚。

• 如果这是静态数据，那么为什么首先将它代理到后端，而不是直接从nginx提供静态数据？ \.png$正则表达式是否与受影响的请求URI不匹配？难道你不能在不涉及后端的情况下解决这个问题，甚至不重写请求而不先将错误的请求发送到后端吗？

• 如果这是非常动态的，那么为什么你需要浪费时间来发出请求只接收不可接受类型的回复，而不是基于你对如何知道的特殊情况映射表该应用程序是否有效，并且从一开始就绕过了不必要的请求，而不是稍后将其丢弃？

• 如果该应用程序确实是一个黑盒子，并且您需要一个适用于任何应用程序的通用解决方案，那么仍然不清楚该用例是什么，以及为什么必须进行额外请求，仅被丢弃。

如果你真的想要在你的image / png示例中只弄乱1％的流量，那么将受影响的1％旧浏览器的所有请求重定向到单独的后端可能是有意义的，这将有逻辑做你需要的。

---

坦率地说，如果你想要真正的旧浏览器，那么我认为png支持应该是你最后的担忧。许多webapps包含非常复杂和特殊用途的JavaScript，甚至不能在具有新User-Agent字符串的新备用浏览器中工作，更不用说任何甚至没有png支持的旧web浏览器。

Answer 2

所以根据http://wiki.nginx.org/HttpCoreModule#.24http_HEADER。我假设你可以有类似的东西 if（$ content_type~＆＃39;无论您的内容类型是什么＆＃39;）{ proxy_pass＆＃39; ur_url＆＃39; }

这会对你有用吗？