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
