Yes it does without any error. I have tested 10 times with no errors
which never happened before and the value of int b does not affected
int rsv. So as far after these test I claim it is fixed in at least
7.0.53. I also filed a bug report for tomcat 7.0.53 and explained the
bug and the solution to update tomcat since it was not in the bug
database at all.
On Thu, Dec 4, 2014 at 4:50 PM, David kerber <dcker...@verizon.net> wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
