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
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
