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
