主页 / server / 问题 / 47148
Accepted
osij2is
Asked: 2009-07-29 10:29:41 +0800 CST

反向代理和 AJAX

  • 772

我们的一个客户正在使用 IBM/Tivoli WebSEAL，这是他们的一些内部用户的反向代理服务器。我们的 Web 应用程序 (ASP.NET 2.0) 是一个相当简单的 Web/数据库应用程序。

目前，我们正在通过 WebSEAL 代理的客户端用户在使用 .NET 第 3 方控件时遇到问题。不通过代理的用户没有问题。第 3 方控件只不过是一个 AJAX 动态树，它在每次单击时请求每个叶子的所有节点。

现在我们的客户声称，一旦用户单击控件中的节点，控件本身就会冻结，以至于他们看不到任何填充内容。用户看到“正在加载...”消息出现，但之后没有新活动。他们必须离开页面并返回原始页面才能查看新节点。

我以前从未使用过反向代理，所以我在这个主题上搜索了很多，甚至找到了一篇关于 SF 的文章。IBM/Tivoli 之前已经提到过这个问题，但这就是他们提到的全部内容。虽然 IBM 文档很有帮助，但我们所有的 AJAX 都来自 3rd 方控制。我尝试使用 Firebug 进行故障排除，但由于不在反向代理后面，我无法真正复制问题。

我的问题是：有没有人有反向代理和 AJAX 网站问题的经验？我怎样才能证明确切的问题是什么？目前我们正在协商远程访问，因此在很大程度上假设我将有权访问使用 WebSEAL 代理的机器。

PS 我意识到这个问题可能会在 StackOverFlow/ServerFault 管辖权辩论中摇摇欲坠，但我正试图从系统的角度进行调查。我没有使用反向代理的经验（我不清楚好处），也没有使用转发代理的经验。

asp.net ibm reverse-proxy

3 个回答

  1. Best Answer

    在获得对我们客户站点的访问权（通过 WebSEAL）并构建测试用例之后，我们就有了答案。根据IBM 关于 AJAX 和 WebSEAL 的文档，在Junction cookie 部分的最后有一段内容如下：

    潜在的解决方案。

    如果来自 AJAX 请求的响应不呈现为 HTML，则不应使用内容类型“text/html”发送响应。应该使用更合适的内容类型，例如“text/plain”。WebSEAL 不会将联结 cookie 代码添加到不具有“text/html”内容类型的响应

    对于我们的 ASP.NET 应用程序，添加到使用该控件的 Page_Load 事件中是一个简单的条件。

       protected void Page_Load(object sender, EventArgs e)
   {

     Response.Clear();

     Response.ContentType = (Page.IsCallback) ? "text/plain" : "text/html";

     //does same thing as line above
     //if (Page.IsCallback)
     //   Response.ContentType = "text/plain";
     //else
     //   Response.ContentType = "text/html";

   }

    我确信其他语言（PHP、JSP、RoR 等）都有改变内容类型的方法。就 ASP.NET 而言，我不确定是否有更好的生命周期事件方法可以将其放入（PreInit？），但这是针对 AJAX 和 IBM WebSEAL 反向代理连接 cookie 的特定问题的有效解决方法。

    • 3

  2. 这可能取决于您的应用程序的工作方式 - 如果它在某些地方使用绝对 URI，并且这些 URI 指向代理背后的用户无法访问的东西 - 这可能是您的问题。

    假设您有代理 P、服务器 S 和用户。服务器有一个给定的主机名（可能更多），其中一个可能与网络服务器相关联（我们称之为 server1）。用户可能会也可能不会直接向 server1 发出请求。很可能，使用反向代理，他们必须向代理发出请求，然后再查询您的服务器。

    他们看到http://P/YourAppHere - 而应用程序实际上位于http://server1/YourAppHere（或其他任意路径）。如果您的应用程序配置为直接引用http://server1/YourAppHere/foo.asp，并且代理不会接受并修改发送给用户的代码以使其指向到http://P/YourAppHere/foo.asp，它会破坏功能。

    有点像在黑暗中刺伤，但我遇到了与 Sharepoint 类似的问题。

    • 1

  3. 对于 WebSEAL 和其他反向代理，您最好的选择是仅使用相对 URL。AJAX 和其他 web 2.0 编码方法的最大问题是他们喜欢将信息发送回客户端，以便客户端创建绝对 URL 客户端。如果需要，反向代理无法过滤此内容。例如，return 的形式为 backendserver.com8443https

    URL= 协议+"://"+host+port+"/somebackendURL/item.html"

    当且仅当绝对 URL 通过反向代理作为

    https://backend.server.com:8443/ 这匹配一个联结的服务器。

    即使您没有像这样编码，连接 cookie 也会产生大量问题。

    如果您有一个 html 页面，其中调用了脚本标签内的 .js 文件，那么如果 .js 文件将 cookie 添加到其中，您将获得嵌套的脚本标签和浏览器 barfs。

    例如 test.html 是你好

    然后这是对 WebSEAL 的 2 个请求。如果他们通过一个带有 junction cookies set 的 junction 最后一页看起来像这样。

    设置 cookie IV_JCT=联结名称

    > 你好

    • 1

相关问题