-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
7
-
x86
-
os_x
FULL PRODUCT VERSION :
JDK 1.7.0 Developer Preview
ADDITIONAL OS VERSION INFORMATION :
Mac OSX Lion
A DESCRIPTION OF THE PROBLEM :
After writing and flushing two chunks of data to an SSLSocket the server side InputStream.available() method does not return the correct number of available bytes of the second chunk until two bytes have been read.
This is due to the following change which splits the first byte of every payload (except the first payload after the handshake):
http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/14d8cc19f227
To have available() returning the real amount of bytes sent, you need to manually read the first two bytes of the payload.
I've created a simple testcase to replicate this behaviour which is available on github:
https://github.com/thomasbecker/sslavailableissue
Note that the test there doesn't have any assertions set. The problem is shown in the debug stdout output only.
The test sends two payloads over the wire.
First payload: "1234567890" which works fine as it is the first after the handshake.
Second payload: "abcdefghijklmnopqrst" which gets the first byte split into it's own record.
For the second payload available() always returns 0 until the first byte of the second record "b" has been read.
This breaks tests and might cause unexpected issues when available() is being used.
REGRESSION. Last worked in version 7
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the test case of the github project shown above.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
available() should return 19 after the first byte of the second payload "a" has been read.
ACTUAL -
available() returns 0 until the 2nd byte of the 2nd payload "b" has been read. Then it returns 18 for the remaining 18 available bytes.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
https://github.com/thomasbecker/sslavailableissue
---------- END SOURCE ----------
JDK 1.7.0 Developer Preview
ADDITIONAL OS VERSION INFORMATION :
Mac OSX Lion
A DESCRIPTION OF THE PROBLEM :
After writing and flushing two chunks of data to an SSLSocket the server side InputStream.available() method does not return the correct number of available bytes of the second chunk until two bytes have been read.
This is due to the following change which splits the first byte of every payload (except the first payload after the handshake):
http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/14d8cc19f227
To have available() returning the real amount of bytes sent, you need to manually read the first two bytes of the payload.
I've created a simple testcase to replicate this behaviour which is available on github:
https://github.com/thomasbecker/sslavailableissue
Note that the test there doesn't have any assertions set. The problem is shown in the debug stdout output only.
The test sends two payloads over the wire.
First payload: "1234567890" which works fine as it is the first after the handshake.
Second payload: "abcdefghijklmnopqrst" which gets the first byte split into it's own record.
For the second payload available() always returns 0 until the first byte of the second record "b" has been read.
This breaks tests and might cause unexpected issues when available() is being used.
REGRESSION. Last worked in version 7
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the test case of the github project shown above.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
available() should return 19 after the first byte of the second payload "a" has been read.
ACTUAL -
available() returns 0 until the 2nd byte of the 2nd payload "b" has been read. Then it returns 18 for the remaining 18 available bytes.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
https://github.com/thomasbecker/sslavailableissue
---------- END SOURCE ----------