On 2/28/2011 11:30 AM, Mark Thomas wrote:
On 28/02/2011 18:11, Filip Hanik - Dev Lists wrote:
[X] Broken - do not release
http://svn.apache.org/viewvc?rev=1075030&view=rev
http://svn.apache.org/viewvc?rev=1074675&view=rev
Are not completely correct implementations as they don't
- support a timeout correctly
That is an issue. Should be a relatively easy fix.
I got this in my code base, I still recommend pulling out the change until all
issues are taken care of.
- dont account for when a write is needed on the selector
I can't figure out what circumstances the handshake process would return
OP_WRITE since it shouldn't ever be waiting for some other process to
write data. Could you explain how this might happen?
When you want to initiate a renegotiating from the server, you want to write data to the client notifying it of such. This happens when you
call beginHandshake.
beginHandshake generates the bytes needed to be sent to the client, so you must
send them.
So we make an attempt to send them. If the attempt to send them fails, meaning no bytes were accepted into the buffer, the handshake(...)
calls returns OP_WRITE to let you know that you can be signaled for when this needs to take place.
This is most unlikely to happen in a scenario like this, as there TCP buffers should have plenty of space in them and we should be able to
take the bytes. However, from a state machine perspective, you still need to account for the state.
The other mistake, is that there is an assumed OP_READ, even if the handshake
completes.
The change will require a bit more careful analysis to get right. Not to
mention, this code, as you may have noticed, is fragile.
- they potentially garble a message body larger than the limit of the
input buffer
This should be handled by the existing code although I didn't test it.
Should be easy to write a unit test to confirm what happens in this case.
Try to start sending a 25MB file upload together with your headers.
Filip
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
