tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Tomcat 3.3 - Cactus Issue
Date Thu, 07 Feb 2002 13:13:08 GMT
Costin,

See inline

> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: 05 February 2002 19:08
> To: Tomcat Developers List
> Subject: Re: Tomcat 3.3 - Cactus Issue
> 
> On Tue, 5 Feb 2002 costinm@covalent.net wrote:
> 
> > 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.
> 
> I'll try again:
> 
> Assuming CLIENT sending data to SERVER. The exception happens when:
>  - server has received some data from client ( so client believes
> the data reached the destionation ). The data is in some OS buffer.
> 
>  - server dies or close() the socket, without reading the data from
> the OS buffer
> 
>  - some OSes have a TCP implementation that does what I believe to
> be right - send an ABORT ( instead of the regular CLOSE ).
> 
>  - the client will receive the ABORT and throw the exception
> ( that coresponds to SIGPIPE if the same thing would be done
> locally )
> 
> 
> ( it seems my original mail was not very clear ).
> 
> My feeling is that we are exaclty in this case - the logic
> to close the socket is trying to read the remaining data from
> the available() buffer ( impl. of the fix for extra CRLF bug ),
> but the impl is likely to fail on a fast OS or on certain
> threading models where the CLIENT may send aditional data
> between we read the input buffer and close().
> 
> 
> Vincent: is your test servlet reading the body i.e. calls
> getParameters() if it's a url-encoded body, or read
> the full stream ?
> 

I do not use getParameters() anywhere in the code because I want to be
able to call getReader() or getInputStream(). Thus I have some utility
code to extract parameter from the query string directly.

-Vincent

> If not, I believe the current behavior is correct and shouldn't
> be changed - it signals the CLIENT that whatever it posted
> was not read, and that's a very usefull information we shouldn't
> hide.
> 
> If this is not the case, and the servlet has read the body -
> than it's a serious problem.
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-
> help@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message