On 12/4/2014 4:32 PM, Jason Ricles wrote:
Yes it was a bug so we will try to get a waiver to use 7.0.57 for our
environment instead of 7.0.53
So it works as expected in 7.0.57?
On Thu, Dec 4, 2014 at 1:20 PM, Jason Ricles <jgr...@alum.lehigh.edu> wrote:
Well the trace is fine so I will upgrade and try and see what happens.
If it is not fixed I assume I should file a bug report.
On Thu, Dec 4, 2014 at 1:19 PM, Mark Thomas <ma...@apache.org> wrote:
On 04/12/2014 18:04, Jason Ricles wrote:
Due to some regulations out of my control right now we can only use
tomcat 7.0.53. I also did a wireshark bug trace and going over the
line the reserved bits are 0 but when computed in tomcat that is when
the reserved are set to invalid bits. Is there any possible solution
or am I just out of luck with tomcat?
If you are stuck on 7.0.53 then you might be out of luck. It depends
what the problem is. The comments on the test case or trace stand but
the response may be "It has been fixed. You need to upgrade".
Mark
On Thu, Dec 4, 2014 at 12:16 PM, Mark Thomas <ma...@apache.org> wrote:
On 04/12/2014 15:26, Jason Ricles wrote:
I have tomcat 7.0.53 and have been having a problem with the following
error when sending a binary message "CloseReason: code [1002], reason
[The client frame set the reserved bits to [x] which was not supported
by this endpoint]" where x is between 1-7 when printed out. So I
remote debugged and stepped through the WsFrameBase.class source code.
This source code is what sets the reserve bit so I stepped through the
following piece of the code
//further up in the code input buffer is set
inputBuffer = new byte[Constants.DEFAULT_BUFFER_SIZE];
//calculation of reserve
int b = inputBuffer[readPos++];
fin = (b & 0x80) > 0;
rsv = (b & 0x70) >>> 4;
if (rsv != 0) {
// Note extensions may use rsv bits but currently no extensions are
// supported
throw new WsIOException(new CloseReason(
CloseCodes.PROTOCOL_ERROR,
sm.getString("wsFrame.wrongRsv", Integer.valueOf(rsv))));
}
However I have noticed when the line "int b = inputBuffer[readPos++];"
it sometimes changes the value of the reserve bit from 0 to a number
between 1-7. Why would this be changing the reserve bit? Is this
possibly an error with what I am doing or an error due to the class
from tomcat that is running?
Most likely a Tomcat bug.
First of all, upgrade to the latest 7.0.x release. There have been fixes
since 7.0.53.
Next, try and create the simplest possible test case to recreate the
issue. Failing that, try capturing a Wireshark trace for the connection
that is failing.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
