Comments below.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 12:45 PM
> To: Tomcat Developers List
> Subject: Re: Tomcat 3.3 - Cactus Issue
>
>
> Hi Larry,
>
> We had a similar problem long time ago - with the POST and the extra
> CRLF. While investigating it, I found a lot of interesting stuff
> about "Connection reset by peer" :-)
The best I can tell, no POST data is sent and none is read, so I
have been assuming this isn't the problem.
>
> Most of the time it happens when something is still in the write
> buffer ( i.e. unsent or unread ), and the remote side is closing
> the connection.
>
> This is the correct behavior, as it signal the sending side that
> whatever it has in the send buffers will be lost. It will
> happen if tomcat doesn't receive the full POST data - it used
> to be the extra CRLF that some browsers sent ( above
> the Content-Length limit ).
>
> The first thing I would check is if the full body was read -
> we already have the workaround for the CRLF bug in TcpConnection,
> but it is possible something is wrong there.
>
> Looking at the code, it may be possible that after
> while( available > 0 ) { is.skip(), available=is.availabe() }
> we may receive some more data.
I believe this code is newer than the last official failure
I heard of from Vincent. I think this was:
if (available > 1) {
is.skip (available);
}
prior to Bill's recent commit to TcpConnection.java.
>
> That's likely to happen on a fast system, and a sleep before
> close() would make it more likely.
>
> The code was supposed to deal with 2 bytes of extra data ( the
> CRLF ), not with some POST body that is supposed to be ignored,
> so it isn't implementing a 'correct' socket.shutdownInput().
>
> One thing to try is to use the JDK1.3 socket.shutdownInput()
> instead ( with a Jdk11Compat workwaround ).
>
> I see no good way to implement this - doesn't matter what
> we do, between reading/skiping data that is available and
> calling close() it is allwasy possible we'll receive more
> data ( we can't 'sync' or anything like that ). It is likely
> the threading model affects that - probably is.available()
> call yields on some OSes, giving the sender an extra chance to
> send more data.
>
> A solution would be to read/ignore the full post body - but that
> is very bad in case of large bodies ( that the servlet may
> decide to ignore ), and for DOS.
>
> Let me know if that helps - and if not what's the easiest way
> to reproduce ( I don't use Windows, but I can find a system
> with W2000, not sure about XP )
I'll see if I can verify if there is any extra input coming
from the client.
To reproduce, I get the Cactus source and with appropriate
build.properties files, I build the "clean", "jar", and "sample"
targets. I then create/copy a build.properties file to the
"../target/servlet22/dist/sample/build" and run the
"tests_tomcat_33" target. There are some additional jars to
add to Ant's lib directory, but I don't have that list off
the top of my head. Let me know if you need any additional
specifics.
Cheers,
Larry
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
