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
