22

希望有人可以帮助我或指出我正确的方向。

我被要求了解如何让 Akamai（或任何其他 CDN 或 NGINX）修改实际的响应正文。

为什么？

我要让 CDN 将所有“http://”请求更改为“https://”，而不是修改 App 代码以将“//”用于外部资源请求。

这可能吗？

有人知道吗？

4

3 回答 3

16

这似乎可以通过多种不同的方法实现，但这并不是说它实际上是 多么可取。

这似乎有潜在的问题（例如：如果你重写不应该重写的东西怎么办？）和机器资源密集型（大量的 CPU 周期来解析和反复处理响应体）。

这是我发现的：

Nginx 有http_sub_module似乎以一种相当简单的方式完成此操作，假设您要替换的内容很简单，并且您只需要在每页匹配一个模式，例如替换<a href="http://example.com/...为<a href="https://example.com/...，一次或多次。这种内容混乱似乎很粗略，但根据您所处的情况（可能是对应用程序的有限控制之一），它可能会让您到达那里。

看起来有一个叫做http_substitutions_filter的东西，可能是非官方的，或者至少不是核心 Nginx 发行版的一部分，它可以对响应体进行更强大的基于过滤器的重写。

Varnish似乎具有类似的功能（可能是插件），但 HAProxy没有，因为它只处理标头并单独处理主体，除非在执行 gzip 卸载时。其他支持反向代理的软件，如 Apache 或 Squid 也可能提供一些有用的东西，您可以将它们放在应用程序服务器的前面。

无论如何，我最初的印象是简单的字符串替换可能无法让你到达那里，甚至基于正则表达式的替换也不够，因为正则表达式没有显着的复杂性，因为你总是冒着重写你的东西的风险不应该。

为了以最正确的方式实现此目的，我建议“确实需要发生”，即使用 DOM 解析库实际解释生成的 HTML，遍历树，并在之前就地修改相关元素将修改后的文件交给请求者。这样，文档会根据对其内容的上下文理解进行修改。

在我看来，这听起来很复杂，因为它是——所以我再次建议你重新考虑你计划的方法，除非这超出了你的控制范围。

最后的想法：好奇心战胜了我，所以我接受了这个问题并改进了我写的 http 反向代理（用于不同的目的），以便根据内容类型，它实际上可以解析和遍历 HTML 结构作为适当的实体，在将响应正文返回给请求者之前对其进行适当的修改（如上所述）。

事实证明，正如我所料，这是相当密集的处理器。我的测试内容是来自实时站点的 29K 真实世界 HTML，包含 56<a href ...>和 6 个<link rel ...>元素，重写操作在 1 GHz Opteron 1218 和 43 ms 2.4GHz Xeon E5620 上需要 128 ms。这些基准严格用于附加操作——不包括实际“代理”功能本身所需的（少量）时间。这个时间成本不是不可克服的，但可能会增加很多 CPU 时间。这比基于正则表达式的内容重写花费的时间要长得多，但它要精确得多，而且不太可能破坏它所触及的页面。

于 2014-09-14T21:05:16.027 回答
13

Nginx 的 HttpSubsModule 非常适合我：http ://wiki.nginx.org/HttpSubsModule

从 http 更改为 https 应该像这样简单：

location / {
    sub_filter_types text/html text/css text/xml;
    sub_filter http.example.com https.example.com gi;
    sub_filter_once off;
}

默认情况下，仅替换第一个匹配项。设置sub_filter_once off;全部替换。

于 2014-11-24T07:26:02.130 回答
8

完全相同，但语法正确。

location / {
    sub_filter_types text/html text/css text/xml;
    sub_filter 'http.example.com' 'https.example.com';
}
于 2017-03-03T15:45:35.330 回答