Handle missing spring headers for ajax redirect [SWF-1376]

[spring-operator]

Daniel Temme opened SWF-1376 and commented

Apparently there is firewall software that defaults to filtering HTTP headers it doesn't know about. This breaks redirect-on-post in ajax requests because both Spring-Redirect-URL and Spring-Modal-View would get filtered out.

The problem is that in these cases Spring.Remoting.handleResponse will just fall through without doing anything or giving an error. It finds no redirect URL and the response body is empty so there is nothing to replace.

It would be nice if in this case the error handler would be called or any error at all would be shown. Otherwise finding customer's problems with their broken firewall configuration (or even figuring out that there is a firewall problem) is pretty cumbersome.

---

No further details from SWF-1376

[spring-operator]

Rossen Stoyanchev commented

Have you checked the Firebug console (or Firebug lite in IE)? There some console messages logged when the content returned doesn't match anything on the page. But these can only be warnings, we can't reasonably assume they're errors without knowledge of the application.

[spring-operator]

Daniel Temme commented

Those warnings will only come if there actually are nodes that can't be replaced. In the case of a POST redirect the body is completely empty and the code just falls through without doing anything. I'm not sure there are valid reasons why you'd have neither a response body nor a spring redirect header.

Also, Firebug and the like are not an option because we can't really ask users of our site to install that to help us debug their overzealous firewall settings.

It's a pretty rare case and it's easy to dismiss error reports as just being some issue with the user's JS settings. Especially because it seems so unlikely that there would be firewalls that filter out HTTP headers. I doubt that if this wasn't in a critical part of our webapp we'd ever figured out what the problem was.

And just to give an example of the firewall settings I found this:
http://watchguard.custhelp.com/app/answers/detail/a_id/1999/~/detailed-information-about-the-http-proxy-%5Bwfs%5D

[spring-operator]

Rossen Stoyanchev commented

I do agree that this is a nasty problem to track down. There is a 'debug' flag in Spring.js, which could be used to decide if such errors should be raised. If you have any code for showing an error feel free to attach a patch.

[spring-operator]

Daniel Temme commented

The more I'm looking into it, the more unsure I am about how to go about the error reporting. I guess there are cases where you would not send a redirect and also not have a response body. I have no problem with throwing an Error in our app because I know we never have empty responses but I'm not sure that can be said for everyone. It could be argued that in these cases the response status should be 204 or 205 but would people set that?

Just using console.error() isn't of much use either because it wouldn't show to the user having the problem.

And I can't check anything in the response because there is no way to determine if it was meant as a redirect without having the header.

This is what I came up with for now:

Index: src/main/resources/META-INF/spring/Spring-Dojo.js

---

--- src/main/resources/META-INF/spring/Spring-Dojo.js (revision 143)
+++ src/main/resources/META-INF/spring/Spring-Dojo.js (working copy)
@@ -498,6 +498,16 @@
}
return response;
}
+

} else if (!response && ioArgs.xhr.status != 204 && ioArgs.xhr.status != 205) {

  var errMsg = "xhr response with neither redirect header or response body.";

  console.error(errMsg);

+// calling the default error handler would also work but it does check for status==200
+// ioArgs.xhr.status = 500;
+// return Spring.remoting.handleError.call(this, errMsg, ioArgs);
+

if (Spring.debug) {

  throw new Error(errMsg);

  }

    }
  
    //Extract and store all <script> elements from the response

[spring-operator]

Rossen Stoyanchev commented

Thanks for posting this. I agree though we cannot assume an empty response body is an error. Hence we probably shouldn't raise an error even if the the debug flag is set. Alternatively, assuming the debug flag is set we could put up a modal dialog that warns the user once (per page) that an empty response with a status code other than 204/205 and no redirect header is a possible error. I think that would fit the debug flag better because it would only serve as a warning.

[spring-operator]

Jeremy Grelle commented

The original problem here brings to light the point that we should probably be prefixing the Spring-specific HTTP headers with "X-", i.e., X-Spring-Redirect-URL and X-Spring-Modal-View. Using an X- prefix is the standard way of specifying "user defined" headers, and these are more likely to not be filtered out by a firewall, proxy, etc.

[spring-operator]

Daniel Temme commented

I agree, switching to "X-" Headers would probably be a good idea.

I'm also slightly back-pedalling from my last back-pedal in that I think defaulting to showing some kind of error dialog probably is the better way to go.

If you do deliberately send empty responses, you would immediately get a feedback that you could act on and work around. Whereas the case of an overzealous firewall is pretty rare and you (and your user) would never get any feedback at all.

[spring-operator]

Rossen Stoyanchev commented

An error dialog is now shown when Spring-Dojo.js detects an empty response, the response code is neither 204, nor 205, and there is no "Spring-Redirect-URL" response header. For the dialog to be shown, Spring.debug must be equal to "true", which is the case by default.

[spring-operator]

Daniel Temme commented

Thanks. I really appreciate this.