Sometimes, the HTTP response sent when NIO connector is used is corrupted. The first line of header contains 16Ko of garbage (0x00) and the next ones are OK. HTTPS was used during the testing. Debugging showed that in a call to NioBlockingSelector.write(,,), the variable buf was correct until it went through this code: if (socket.getBufHandler().getWriteBuffer() != buf) { socket.getBufHandler().getWriteBuffer().put(buf); buf = socket.getBufHandler().getWriteBuffer(); } After appending a ByteBuffer to another ByteBuffer, one shoud take some extra step to flip the buffer (prepare for read after write) See enclosed patch for a fix validated to correct the issue.
Created attachment 21006 [details] Patch for issue 43653 Tested under Windows 2000, tomcat 6.0.14
are you able to provide a test case, My spider man intuition tells me the fix should be somewhere else in the code, and not in the blocking selector code, but probably in the SecureNioChannel Filip
Created attachment 21007 [details] Correct patch for buffer handling during SSL This is the correct patch, the selector shouldn't do anything to the buffer. The bug that happened is caused by the fact that the data from the SSL network buffer gets stuffed into the application buffer
Created attachment 21008 [details] Correct patch this time Must make sure the correct buffer gets written
Additional info: occurs while sending HTTP/1.1 100 Continue Second and third patch did not fix the issue (reopen).
Created attachment 21012 [details] "Tested to work correctly" patch update Finally a working patch that is correct ?
Created attachment 21015 [details] Remainder of the patch Since the previous patch was applied, this is the remainder
This was fixed a little while ago and has been included in 6.0.16 onwards.