| Summary: | NIO connector may corrupt first line of HTTP/1.1 100 Continue response | ||
|---|---|---|---|
| Product: | Tomcat 6 | Reporter: | Christophe Pierret <cpierret> |
| Component: | Connectors | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | P2 | ||
| Version: | 6.0.14 | ||
| Target Milestone: | default | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Attachments: |
Patch for issue 43653
Correct patch for buffer handling during SSL Correct patch this time "Tested to work correctly" patch update Remainder of the patch |
||
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. |
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.