2

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.

3 Answers 3

3

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.

1

It may depend on how your application works - if it uses absolute URIs in places, and those point to something that users behind the proxy cant get to - that may be your problem.

Say you have proxy P, server S, and the user. the server has a given hostname (possibly more) and one of those is probably associated with the webserver (lets call it server1). Users may or may not be able to make requests directly to server1. In all likelihood, with a reverse proxy, they have to make requests to the proxy, and that in turn queries your server.

They see http://P/YourAppHere - while the app actually lives at http://server1/YourAppHere (or some other arbitrary path). If your app is configured in such a way as to make direct reference to http://server1/YourAppHere/foo.asp, and the proxy doesnt pick up on that and modify the code that gets sent to the user to so that it directs to http://P/YourAppHere/foo.asp, it will break functionality.

Kind of a stab in the dark here, but i ran into a similar issue with Sharepoint.

3
  • Yeah, URL paths seem to be an issue, but I don't know how URL paths are built in the 3rd party control. Would stepping through using Firebug show a path problem?
    – osij2is
    Jul 28, 2009 at 20:25
  • if the problem is as ive laid out here, yes. the code would be on the client machine in an form that will fail when the request is made. i dont even think youd need firebug if you know/have likely candidates for the name of the server - just search for that. alternatively, any URI that doesnt start with http://P
    – Devnull
    Jul 28, 2009 at 20:35
  • Thanks for the suggestion. I'll have to investigate that idea and see what I can dig up.
    – osij2is
    Jul 28, 2009 at 20:51
1

With WebSEAL and other reverse Proxies your best bet is to only use relative URLs. The biggest issue with AJAX and other web 2.0 coding methods is that they love sending information back to the client for the client to create absolute URLs client side. There is no way for the Reverse proxy to filter this if needed. e.g. return is of the form backendserver.com8443https

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

Absolute URLs are filtered if and only if it goes through the Reverse proxy as

https://backend.server.com:8443/ and this matches a junctioned server.

Junction cookies create a large number of problems even if you are not coding like this.

If you have a html page with a call to a .js file inside a script tag then if the .js file gets the cookie added to it you get nested script tags and the browser barfs.

e.g. test.html is hello

Then this is 2 requests to WebSEAL. If they go through a junction with junction cookies set The final page looks something like.

set cookie IV_JCT=junctionname

> hello

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .