Bug 43653 - NIO connector may corrupt first line of HTTP/1.1 100 Continue response
NIO connector may corrupt first line of HTTP/1.1 100 Continue response
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Connectors
6.0.14
PC Windows 2000
: P2 major (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-10-18 10:43 UTC by Christophe Pierret
Modified: 2008-04-19 10:29 UTC (History)
0 users



Attachments
Patch for issue 43653 (1.74 KB, patch)
2007-10-18 10:44 UTC, Christophe Pierret
Details | Diff
Correct patch for buffer handling during SSL (1.55 KB, patch)
2007-10-18 12:22 UTC, Filip Hanik
Details | Diff
Correct patch this time (4.68 KB, patch)
2007-10-18 12:38 UTC, Filip Hanik
Details | Diff
"Tested to work correctly" patch update (5.54 KB, patch)
2007-10-19 11:45 UTC, Christophe Pierret
Details | Diff
Remainder of the patch (786 bytes, patch)
2007-10-20 08:43 UTC, Filip Hanik
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Pierret 2007-10-18 10:43:39 UTC
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.
Comment 1 Christophe Pierret 2007-10-18 10:44:28 UTC
Created attachment 21006 [details]
Patch for issue 43653

Tested under Windows 2000, tomcat 6.0.14
Comment 2 Filip Hanik 2007-10-18 11:25:42 UTC
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
Comment 3 Filip Hanik 2007-10-18 12:22:54 UTC
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
Comment 4 Filip Hanik 2007-10-18 12:38:15 UTC
Created attachment 21008 [details]
Correct patch this time

Must make sure the correct buffer gets written
Comment 5 Christophe Pierret 2007-10-19 11:15:12 UTC
Additional info: occurs while sending HTTP/1.1 100 Continue
Second and third patch did not fix the issue (reopen).
Comment 6 Christophe Pierret 2007-10-19 11:45:28 UTC
Created attachment 21012 [details]
"Tested to work correctly" patch update

Finally a working patch that is correct ?
Comment 7 Filip Hanik 2007-10-20 08:43:36 UTC
Created attachment 21015 [details]
Remainder of the patch

Since the previous patch was applied, this is the remainder
Comment 8 Mark Thomas 2008-04-19 10:29:10 UTC
This was fixed a little while ago and has been included in 6.0.16 onwards.