Reverse Proxies and AJAX

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.

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.

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.

> hello