Are bug fixes in Tomcat Code automatically picked up in Jboss Web?

[helweg]

I believe I ran into a bug (using JBoss Version 7.1.1)  that was possibly (according to this comment https://issues.apache.org/bugzilla/show_bug.cgi?id=53677#c1) fixed in Tomcat 7.0.x:

https://issues.apache.org/bugzilla/show_bug.cgi?id=53677

Will this automatically be picked up for Jboss Web?

As far as I understand parts of Jboss Web is still coming from Tomcat (even though it is a complete fork now).

I also found a mapping of what version of Jboss Web is contained in JBoss AS and what version of Tomcat Jboss Web is/was based on:

https://community.jboss.org/wiki/VersionOfTomcatInJBossAS

Still I am not sure if this specific bug is supposed to be fixed in Jboss Web 7.0.10 (which is the version in Jboss AS 7.1.1 which I am using).

I am currently facing this problem while a response is creating a way too big header which exceeds the maxHttpHeaderSize (I guess even by far).

Consequently it throws an ArrayIndexOutOfBoundsException and later on seam transaction already in use exceptions - possibly as a result of the ArrayIndexOutOfBoundsException and an error in not rolling back the seam transaction when this happens.

[jfclere]

Not all the tomcat bugs apply to jbossweb. Our code is based on a fork of tomcat6 for this particular bug it can't be fixed easely. (See last comment in the bugzilla).

I think you should open a JIRA so we can track the issue and fix it.

[helweg]

Our code is based on a fork of tomcat6

I guess that means that the parts/classes that are actually untouched will also never get updated?

I don't know about the changes that were made in jbossweb since the fork. I thought maybe the changes affect only certain parts of the tomcat code and that there still is a common base that is kept synchronous with the tomcat base (if that is technically possible at all).

Anyways, I create a bug in Jira:

https://issues.jboss.org/browse/JBWEB-265

[rmaucher]

No, patches porting is not automatic. This is specifically something that will not be addressed, as it is not a bug. Adding checks everywhere that mimic the array bound checks is plain useless.

[helweg]

Ok, if adding checks to avaoid this is useless, then maybe you have a hint on how this should be solved?

This is what happens:

I am using a SAML based authentication mechanism (with Jboss Security based on picketlink).

In the process of authentication the identity provider sends a html-form to the browser with one hidden value (which contains the xml-based authentication response) and javascript that posts the form automatically within an onload event to my Jboss app.

Then the the jboss security code will handle this request. In my special case the jboss security code throws an InvalidRequestException and packs this into a RuntimeException (which is ok, because there is an error in the response).

As there is no further handling of this RuntimeException the servlet container will handle it and tries to generate the standard 500 error page.

For a reason I don't know the one hidden value of the posted form is attached as a GET parameter to the URL and the URL is written into the http header to the attribute "location". (I neither know where this happens nor why this happens at all). This one parameter is the complete base64 encoded XML-Respone which is too big and therefore breaks the max header size and this results to the ArrayIndexOutOfBoundsException.

Another effect is that (as a dependency of the jboss security artefact) jboss seam is included and this alone starts seam transaction handling for incoming http requests. The ArrayIndexOutOfBoundsException seems to break the transaction handling as the transaction is not rolled back. And after all this the one thread will always respond with "thread is already associated with a transaction...".

I know this is not all jbossweb related but maybe you have an idea as to where you would start solving this?

[jfclere]

Ok "the complete base64 encoded XML-Respone which is too big and therefore breaks the max header size", then does increasing the org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE system property help?


[helweg]

Thanks for your help.

No it does not. I tried to double the size but read somewhere that on windows systems this can not be arbitrarly increased and when I doubled the size (to 16k) the limit was set to something around 12k (while 8k is the default). And I think I somewhere read that around 12k is actually the max size on windows systems (I have no idea why this would be different on windows though).

I haven't checked the actual size of the complete base64 encoded XML-Response, but 12k was also not sufficient.

So far we have a quick fix and catch the RuntimeException and do a redirect ourselves. This way there is no default error handling and no writing of the complete response to the header and consequently no array index out of bounds...

But it feels like a quick fix and not like a real problem solution.

[jfclere]

"No it does not" that is _very_ weird.

What is the exception? (where is it in the InternalOutputBuffer.java in that version of AS7).

[helweg]

Why is that weird? The size is indeed increased. Default is 8k. I have set it to 16k. Due to the windows system it seems to be limited to ~12k.

But however, I think the base64 encoded xml is even greater then 12k so I still get the same ArrayIndexOutOfBoundsException.

Unfortunately I do not have the code in front of me right now so I can not look up where in the InternalOutputBuffer it is.

The thing that concerns me more is: When a RuntimeException is handled while processing a form why would a post parameter from that form be attached to the URL that is written into the http header? That does not make sense to me...

[jfclere]

I don't see what it is limited to ~12K.

I am still waiting for the stack trace to look further to the problem....

[helweg]

Attached is a stacktrace of the original error.

I also found the place where I read about "ominous" windows limit of 12k:

https://issues.jboss.org/browse/AS7-3953

However, while I reproduced this I had a look at this again and it turns out that my buffer with the response has the size of 12231 bytes.

And that my way of changing the maxHttpHeaderSize on Jboss 7.1 does not seem to have any effect:

I tried to change this by setting a system property in standalone.xml like this:

    <system-properties>

        <property name="org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE" value="32768"/>

    </system-properties>

But it turns out it is still set to 8192.

So I guess I need to find how to really increase this first....

[jfclere]

r1987 added the org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE so in jbossweb version 7.0.12.

<version.org.jboss.web>7.0.13.Final</version.org.jboss.web> in AS 7.1.1 it should work.

You are using jbossweb-7.0.10.Final.jar that is AS-7.1.0.Final:  (using JBoss Version 7.1.1 = false). So please update to a newer version.

[helweg]

Oh, you are right. I am using 7.1.0 instead of 7.1.1 (I thought I already upgraded this some time ago - sorry for the confusion).

I will try that...

[helweg]

Unfortunately I can't get the Jboss 7.1.1 version to work (with picketlink - which I need for the SAML authentication).

There seems to be class loading problems in Jboss 7.1.1 and the bundled version of picketlink 2.0.2 which are described in this forum thread:

https://community.jboss.org/thread/196214

There is a workaround described in that thread and also a wiki article on how to overcome this:

https://community.jboss.org/wiki/HowToConfigurePicketLink202WithJBossAS711

I did all that but still get the error:

java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory: javax.faces.FacesException: #{samlIdentity.login()}: java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory

Maybe this is realted to this ticket in Jboss 7.1.1:

https://issues.jboss.org/browse/AS7-4248

Sorry, I really appreciate your help and would love to prove that changing the max http header size prevents the array index out of bound but I guess my limited knowledge to circumvent the problems describes above (and limited project time) defeats me.

Btw:

I'm still thinking that an even better solution (better than changing the max http header size) would be to prevent the post paramter (that base64 encoded xml response) being attached as a GET parameter to the URL that is written to the header. I still don't know why this is done at all and also where this happens.

[jfclere]

Ok the logic that adds the post to the header is in seam-security-external-3.1.0.Final.jar you should ask that question to a seam forum.