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?

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

Reply via email to