我们正在努力将 ASP 站点转换为 ASP.Net，并且遇到了重定向和资源位置的问题。我们的问题来自我们设置的特殊性。我们的网站可以通过两种方式访问：
- 直接通过 URL：http ://www.mysite.com - 在这种情况下一切正常
- 通过具有如下 URL 的代理服务器：http: //www.proxy.com/mysite_proxy/proxy/
在#2中，“mysite_proxy”是proxy.com上的一个映射，它将幕后的请求定向到www.mysite.com，“proxy”是一个虚拟子网站，它只是将请求重定向到www.mysite.com的根目录. 它本质上是为了给我们一种方便的方式来了解请求是否从代理访问站点。
我们在这个设置中遇到了两个问题：
- 将 Response.Redirect 与“~”或纯相对路径 (Default.aspx) 一起使用会生成位置为“/proxy/rest_of_the_path.aspx”的 302 响应。这会导致浏览器请求http://www.proxy.com/proxy/rest_of_the_path.aspx，它什么都不是，甚至没有访问我们的服务器，所以我们无法在事后重写。
- 在我们的页面中为链接、图像、样式表等使用基于“~”的 URL 会创建相同类型的路径：“/proxy/path_to_resources.css”。我们可能可以通过对所有这些资源使用相对路径来解决其中的一些问题，尽管这将是很多工作，并且对于解决由框架和第 3 方组件生成的类似资源链接无济于事。
理想情况下，我想找到一个全局修复程序，使这些问题对网站上的开发人员透明。在这一点上，我有几个想法：
- 摆脱代理，它并不是真正需要的，并且是出于管理而非技术原因。在技术上最容易完成，在现实世界中最难完成。
- 将问题交给运行代理的小组，并说这是他们需要解决的问题。
- 使用响应过滤器在原始 html 发送到客户端之前对其进行修改。我知道这可以修复我的资源链接，但我不确定标头（需要对其进行测试），并且必须解析每个响应以查找和重写 url，这会对性能造成影响。
所有这些解决方案在我心中都有很大的负面影响，我希望有人可能有另一个想法。那么有什么想法吗？
另外：已经有很多帖子处理了这个问题的反面：我有一个相对 URL，我怎么可能是绝对的，但我没有遇到任何适合另一个方向的东西。