修改HTML响应(不是标题)

Question

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

我被要求了解如何使Akamai(或任何其他CDN或NGINX)修改实际的响应体.

为什么？

我要让CDN将所有"http://"请求更改为"https://",而不是修改App代码以使用"//"来表示外部资源请求.

这可能吗？

谁知道？

Answer 1

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

这似乎有问题(例如:如果你重写了一些本不应该被重写的内容？)和机器资源密集型(很多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时间.这比基于正则表达式的内容重写要长得多,但它更精确,不太可能破坏它接触的页面.

Answer 2

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

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

location / {
    subs_filter_types text/html text/css text/xml;
    subs_filter http.example.com https.example.com gi;
}

Answer 3

只是一样,但正确的语法.

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