Created attachment 36071 [details] Contrived example to trigger BufferOverflowException in WsWebSocketContainer#connectToServer WsWebSocketContainer#connectToServer throws BufferOverflowException when headers supplied by ClientEndpointConfig.Configurator#beforeRequest are too large. Exception in thread "main" java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:189) at java.nio.ByteBuffer.put(ByteBuffer.java:859) at org.apache.tomcat.websocket.WsWebSocketContainer.addHeader(WsWebSocketContainer.java:755) at org.apache.tomcat.websocket.WsWebSocketContainer.createRequest(WsWebSocketContainer.java:736) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServerRecursive(WsWebSocketContainer.java:275) at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:195) In our application, we are forwarding an Authorization header/token of close to 4000 bytes, which when combined with other headers results in a request larger than the 4096 allocated to the ByteBuffer in WsWebSocketContainer#createRequest. Suggest making this buffer size configurable via a new setting in org.apache.tomcat.websocket.Constants. I can contribute a fix if that is appropriate. Our local patch has the following in Constants: static final int WS_UPGRADE_REQUEST_SIZE = Integer.getInteger( "org.apache.tomcat.websocket.WS_UPGRADE_REQUEST_SIZE", 8 * 1024) .intValue(); So, a new default buffer size of 8k, and the option of setting a system property if it needs to be bumped up further. I've attached some code that will trigger the exception.
I'm leaning more towards simply auto-expanding the buffer until it is big enough. I'm not concerned about memory issues as the user is in control of the headers they send.
That makes sense.
Fixed in: - trunk for 9.0.11 onwards - 8.5.x for 8.5.33 onwards - 7.0.x for 7.0.91 onwards