0 Replies Latest reply on Aug 14, 2007 5:39 PM by John Boardman

    RFC2616 violation causes failure with Microsoft ISA reverse

    John Boardman Newbie

      Ajax4JSF 1.1.1 sends both the "content-length" header and the "transfer-encoding: chunked" header when responding to requests. This violates RFC 2616 which states that only one of those two may be send in any particular request or response. This error makes it impossible to deploy in an environment where Microsoft's ISA reverse proxy is used. ISA detects the violation and rejects the request for AjaxScript.jsf, which effectively disables ajax4jsf.

      I have fixed this issue in the ajax4jsf code, but I don't know if it is the best fix that can be made for the problem. It certainly works for my tests, and I have to use my fix at least until an "approved" fix can be made.

      2 files are changed to fix the issue. They are:
      framework\src\main\java\org\ajax4jsf\framework\ajax\xmlfilter\CacheContent.java
      and
      framework\src\main\java\org\ajax4jsf\framework\resource\InternetResourceBase.java

      The fix for CacheContent.java is to change line 130 from

      if (filledOutputStream && content.length > 0) {

      to
      if (filledOutputStream && null != content && content.length > 0) {


      The fix for InternetResourceBase.java is to comment out line 372 (371-373 is shown)
      if (isCacheable(null)) {
       //setContentLength(total);
      }


      since we don't want the content length set just because the content is cacheable. These two changes remove the "content-length" header from the response while leaving the "transfer-encoding: chunked" header intact. Like I mentioned, I don't know if this is the best fix, or will work in all situations, but I use a large amount of a4j tags in my 1.1 facelets app and it now works properly behind a reverse proxy (ISA in particular). I've also tested it behind Squid in reverse proxy mode on linux and it worked there too.

      I wanted to get these fixes out to the developers of ajax4jsf so they could either be implemented in the next release or implement a better solution than I found. I would also imagine other people are seeing the same problem and possibly not knowing what to do about it.

      Incidentally, the problem exposes itself with a response from ISA that looks like:

      "Access denied due to security policy violation
      Reject ID: 4413c581-0-112f3c3-7b6"

      when /a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.jsf is requested. The Reject ID will vary. I don't know why.

      Thanks,
      John Boardman