https://bz.apache.org/bugzilla/show_bug.cgi?id=65448
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #28 from Mark Thomas <ma...@apache.org> ---
I was waiting for your test results before pushing the fix. This is the 9.0.x
fix:
https://github.com/apache/tomcat/commit/171a2cdc
The reason it is hard to reproduce is that it requires a specific set of
circumstances that are affected by timing.
The NIO connector uses a Poller when it needs to simulate blocking. If a write
can't complete immediately, the socket is added to the Poller and the write
continues when the Poller signals that the socket is ready for write.
The problem was the way Tomcat handled TLS writes. If the final non-encrypted
write for a response was fully encrypted but the encrypted data could not be
fully written, the socket was not added to the Poller. The final block of
encrypted data sat in the buffers until the connection timed out - at which
point it was flushed.
I was able to simulate this by configuring a VM with a slow connection
(128kbps) and then writing an ~80k file. By carefully adjusting the length of
the file, I was able to trigger this every time.
In a real system, triggering the issue would depend on how busy the network
stack was, how quickly the client read, the exact size of the response
(including headers) etc. The odds of hitting the exact combination are slim.
Fixed in:
- 10.1.x for 10.1.0-M3 onwards
- 10.0.x for 10.0.9 onwards
- 9.0.x for 9.0.51 onwards
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
