tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Ricles <jgr...@alum.lehigh.edu>
Subject Re: Error with finding of reserve bits in websocket frame tomcat 7.0.53?
Date Thu, 04 Dec 2014 21:32:37 GMT
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 <jgr208@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 <markt@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 <markt@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message