操纵 HTTP 响应

Question

我当前的问题与this one 密切相关，但更为具体。我们必须为该问题中描述的目标制定设计策略。

我们希望通过在 ASP.NET Web 表单上重写 HTML 来做到这一点。我的问题是：根据可行性、性能影响和对遗留应用程序的实施工作等参数，哪种策略最好。

我必须做什么

基本上就是获取一个Web Form的HTML输出，解析它，根据用户定义的规则替换某些URL。在该示例中，我会将所有静态内容重写为 CDN URL，但它可以轻松扩展到 URL 重写技术。从将http://myblog.com/2092 之类的URL 解释为http://myblog.com/Default.aspx?post=2092 的角度来看，我发现很多（我的真正意思是很多）关于URL 重写的文章，但我发现没有一个显示我如何在 HTML 内部巧妙地将旧式 URL 格式化为更短的格式（因此页面将直接呈现短格式 URL）[编辑]，无需深度代码干预。

策略 1

就像在上述问题的答案中建议的那样，编写一个拦截 HTML 并重写它的 HTTP 模块。实际上，我环顾四周，发现我可以设置一个执行 HTML 过滤的Response.Filter 流对象。

• 优点：我可以在遗留应用程序中注入 HTTP 模块，通过 XML 配置重写规则，并让最古老的 CRM/电子商务应用程序从 CDN 加载静态内容，而无需接触其代码完全。
• 缺点：我怀疑（并且评论here 证实了我的怀疑）必须重新实现Stream 的Write 方法，该方法在一般情况下对部分缓冲区进行操作，可能会导致替换错误。假设 Write 方法首先使用ttp://mydomain.com/static/ima 之类的块调用（我假设<img src="h 之前已经编写过），然后使用http://mydomain.com/static/[^"]* 正则表达式的重写规则调用ge.png" />（所以猜测最终的URL :-P）到http://cdn.com/path/$1，替换没有完成。为了解决这个问题，我可以使用 MemoryStream 或类似的东西来缓冲完整的数据集，然后执行替换，但它可能会在高负载服务器上造成问题

策略 2

以here 所述的方式覆盖Page 的Render 方法

• 优点：不会遇到分块问题
• 缺点：需要为所有页面定义一个基类。对新应用程序可行，不确定是否维护旧版应用程序。似乎有问题，因为您无法直接实例化 HttpTextWriter

显然，对于我们必须开发的新 Web 应用程序，我会采用策略 2，但我非常喜欢使用 动态组件，因为它们可以在应用程序需要时轻松插入（因此，如果我们的新应用将在没有 CDN 的情况下安装，则该功能将被关闭）。

简单来说，我的问题是

您将如何解决这两种策略的缺点（尤其是第一种）？当然，您还有其他策略可以建议来实现这一目标吗？

谢谢。

Answer 1

也许您可以使用 ASP.NET 的“自适应控制行为”功能。见Architectural Overview of Adaptive Control Behavior

基本上您会重新定义一个新的HtmlTextWriter 类，将其关联为默认渲染器，并用您自己的代码覆盖“A”标记渲染。