ASP.Net 相对重定向和资源路径

Question

我们正在努力将 ASP 站点转换为 ASP.Net，但在重定向和资源位置方面遇到了问题。我们的问题来自我们设置的特殊性。可以通过两种方式访问​​我们的网站：

1. 直接通过 URL：http://www.mysite.com - 在这种情况下一切正常
2. 通过具有如下 URL 的代理服务器：http://www.proxy.com/mysite_proxy/proxy/

在#2 中，“mysite_proxy”是proxy.com 上的一个映射，它将幕后的请求定向到www.mysite.com，“proxy”是一个虚拟子网站，它只是将请求重定向到www 的根目录。 mysite.com。它本质上是为了给我们一种方便的方式来了解请求是否从代理访问站点。

我们在这个设置中遇到了两个问题：

1. 使用带有“~”或普通相对路径 (Default.aspx) 的 Response.Redirect 会生成位置为“/proxy/rest_of_the_path.aspx”的 302 响应。这会导致浏览器请求http://www.proxy.com/proxy/rest_of_the_path.aspx，这不是任何东西，甚至不会访问我们的服务器，因此我们无法事后重写。
2. 在我们的页面中为链接、图像、样式表等使用基于“~”的 URL 会创建相同类型的路径：“/proxy/path_to_resources.css”。我们可能可以通过对所有这些资源使用相对路径来解决其中的一些问题，尽管这将是大量工作，并且对于解决由框架和第 3 方组件生成的类似资源链接无济于事。

理想情况下，我希望找到一个全局修复程序，使这些问题对网站上的开发人员透明。在这一点上我有一些想法：

1. 摆脱代理，它并不是真正需要的，它是出于管理而非技术原因。在技​​术上最容易完成，在现实世界中最难完成。
2. 将问题交给运行代理的小组，并说这是他们需要解决的问题。
3. 使用响应过滤器在原始 html 发送到客户端之前对其进行修改。我知道这可以修复我的资源链接，但我不确定标头（需要对其进行测试），并且必须解析每个响应以查找和重写 url，这会对性能造成影响。

所有这些解决方案在我看来都有很大的负面影响，我希望有人可能有其他想法。那么有什么想法吗？

除此之外：已经有很多帖子处理了这个问题的反面：我有一个相对 URL，我怎么可能是绝对的，但我没有遇到任何符合另一个要求的东西方向。

Answer 1

作为修复，我会在 Global.asax:Session_Start 使用一个小的检测例程（因为我认为代理实际上并没有启动另一个应用程序实例），使用正确的路径设置会话变量，然后使用它而不是 '~'。

如果使用不同的应用程序实例，则使用 Application_Start 代替 Session_Start 并使用静态全局变量代替 Session 变量。