2

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

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

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

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

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

4

2 回答 2

1

尽管我确信做你想做的事可能有正当的理由，但你的实际image/png例子并不像看起来那么简单。浏览器不再像过去那样在 png 是新的时候包含image/png在其HTTP 请求标头中，因此，您必须拥有真正非常旧的浏览器的整个检测和映射表。Accept

此外，从架构的角度来看，您要完成的工作并不是很清楚。

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

  • 如果这真的是动态的，那么为什么你需要浪费时间来发出请求，只是为了接收不可接受的类型的回复，而不是根据你对应用程序如何工作的了解来获得特殊情况的映射表，并绕过从一开始就不需要的请求，而不是以后丢弃它们？

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

如果您真的希望像图像/png 示例中那样只处理 1% 的流量，那么将所有请求从受影响的 1% 旧浏览器重定向到单独的后端可能是有意义的，这将有做你需要的逻辑。

坦率地说，如果您想针对真正非常旧的浏览器，那么我认为 png 支持应该是您最后的担忧。许多 web 应用程序包含非常复杂和特殊用途的 JavaScript，它们甚至无法在具有新用户代理字符串的新替代浏览器中工作，更不用说任何甚至不支持 png 的旧 web 浏览器了。

于 2014-03-05T14:51:31.923 回答
0

所以根据 http://wiki.nginx.org/HttpCoreModule#.24http_HEADER。我假设你可以有一些类似 if ($content_type ~ 'whatever your content type') { proxy_pass 'ur_url' }

那对你有用吗？

于 2014-03-05T19:56:13.987 回答