TooTallNate/Java-WebSocket · error · IllegalStateException
Size representation not supported/specified
Error message
Size representation not supported/specified
What it means
createByteBufferFromFramedata writes the frame length using 7/16/64-bit representations; the computed sizebytes value must be 0, 2, or 8. Any other value means an internal inconsistency (invalid payload length) and the code throws this IllegalStateException before the frame can be serialized.
Solutions
- Ensure the payload ByteBuffer has a non-negative, RFC-valid remaining() size before createBinaryFrame
- Do not manually mutate frame length fields; build frames via the library APIs (send, continuousFrame)
- Check that total message sizes stay within 64-bit unsigned length limits
- Catch/inspect in a debugger to find where the bad length originates
Example fix
// before frame.setPayload(ByteBuffer.allocate(-1)); // after frame.setPayload(ByteBuffer.allocate(payloadSize)); // payloadSize >= 0
Defensive patterns
Strategy: validation
Validate before calling
private static boolean isEncodableLength(ByteBuffer payload) {
return payload != null && payload.remaining() >= 0;
}
// call before createBinaryFrame: if (!isEncodableLength(payload)) skip; Type guard
boolean isEncodableLength(ByteBuffer b) { return b != null && b.remaining() >= 0; } Try / catch
try {
ws.send(payload);
} catch (IllegalStateException e) {
if ("Size representation not supported/specified".equals(e.getMessage()))
logger.error("Frame length cannot be encoded — payload buffer corrupted");
} Prevention
- Build frames only through library APIs, never set length fields manually
- Verify payload buffers are allocated with non-negative sizes
- Investigate custom Draft subclasses that tamper with frame lengths
When it happens
Trigger: Attempting to serialize a frame whose payload length does not map to a supported length encoding, usually via createBinaryFrame on a frame built with a corrupted or out-of-range length (negative payload or length overflow beyond 64-bit representation).
Common situations: Custom Draft/subclass code building frames with hand-set payload lengths, payload ByteBuffers with negative remaining(), constructing frames with sizes outside RFC 6455 bounds.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- Only Opcode.BINARY or Opcode.TEXT are allowed
- 1002
- buffer size < 0
- parameter must not be null
- Invalid SSL status:
AI-assisted analysis of TooTallNate/Java-WebSocket@afeacbf8c0 (2026-09-09).
Data as JSON: /api/errors/246eeb6e2b70fa7a.
Report an issue: GitHub.
Appendix: source
Thrown at src/main/java/org/java_websocket/drafts/Draft_6455.java:509
one |= getRSVByte(2);
}
if (framedata.isRSV3()) {
one |= getRSVByte(3);
}
buf.put(one);
byte[] payloadlengthbytes = toByteArray(mes.remaining(), sizebytes);
assert (payloadlengthbytes.length == sizebytes);
if (sizebytes == 1) {
buf.put((byte) (payloadlengthbytes[0] | getMaskByte(mask)));
} else if (sizebytes == 2) {
buf.put((byte) ((byte) 126 | getMaskByte(mask)));
buf.put(payloadlengthbytes);
} else if (sizebytes == 8) {
buf.put((byte) ((byte) 127 | getMaskByte(mask)));
buf.put(payloadlengthbytes);
} else {
throw new IllegalStateException("Size representation not supported/specified");
}
if (mask) {
ByteBuffer maskkey = ByteBuffer.allocate(4);
maskkey.putInt(reuseableRandom.nextInt());
buf.put(maskkey.array());
for (int i = 0; mes.hasRemaining(); i++) {
buf.put((byte) (mes.get() ^ maskkey.get(i % 4)));
}
} else {
buf.put(mes);
//Reset the position of the bytebuffer e.g. for additional use
mes.flip();
}
assert (buf.remaining() == 0) : buf.remaining();
buf.flip();
return buf;
}
View on GitHub (pinned to afeacbf8c0)