Reverse Proxies and AJAX

asp.netibmreverse-proxy

A client of ours is using IBM/Tivoli WebSEAL, a reverse-proxy server for some of their internal users. Our web application (ASP.NET 2.0) and is a fairly straightforward web/database application.

Currently, our client users that are going through the WebSEAL proxy are having problems with a .NET 3rd party control. Users who are not going through the proxy have no issues. The 3rd party control is nothing more than an AJAX dynamic tree that on each click requests all the nodes for each leaf.

Now our clients claim that once users click on a node in the control, the control itself freezes in such a way that they don't see anything populate. Users see "Loading…" message appear but no new activity there afterwards. They have to leave the page and go back to the original page in order to view the new nodes.

I've never worked with a reverse proxy before so I have googled quite a bit on the subject even found an article on SF. IBM/Tivoli has mentioned this issue before but this is about all they mention at all. While the IBM doc is very helpful, all of our AJAX is from the 3rd party control. I've tried troubleshooting using Firebug but by not being behind the reverse proxy, I'm unable to truly replicate the problem.

My question is: does anyone have experience with reverse proxies and issues with AJAX sites? How can I go about proving what the exact issue is? Currently we're negotiating remote access so assume for the greater part that I will have access to a machine that's using the WebSEAL proxy.

P.S. I realize this question might teeter on the StackOverFlow/ServerFault jurisdictional debate, but I'm trying to investigate from the systems perspective. I have no experience with reverse proxies (and I'm unclear on the benefits) and little with forwarding proxies.

Best Answer

Well after obtaining access to our client's site (through WebSEAL) and building a test case, we have an answer. According to IBM's documentation on AJAX and WebSEAL, at the very end on the section of Junction cookies there's a paragraph that reads:

Potential solution.

If the response from an AJAX request is not to be rendered as HTML, the response should not be sent with a content type of "text/html". A more appropriate content type should be used, for example, "text/plain". WebSEAL does not add the junction cookie code to responses that do not have a content type of "text/html"

For our ASP.NET application, it was a simple condition to add into the Page_Load event that used the control. 

   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";

   }

I'm sure that other languages (PHP,JSP,RoR,etc.) all have ways of altering content type. In terms of ASP.NET, I'm not sure if there's a better lifecycle event method to put this in (PreInit?), but this is an effective workaround for this specific issue with AJAX and IBM WebSEAL reverse proxy junction cookies.

Related Topic