DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36448>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36448 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:39 ------- > So Joe's right, it could be this > 'extra' 100 continue is in response to the subsequent request. But it's > altogether invalid as a 'keepalive indicator' between requests. Yep! The 1xx is valid between the response and the final request but ^not^ after final response and ^before^ the subsequent request. At least this is my understanding of section 10.1 in rfc 2616. I am just wondering if there is a better way to check whether the socket communication is still alive without trying to read at least one byte from the socket? IMHO there is no way of doing this at least not for the portable code?! Another solution to this problem could be let say trying to read a byte and if it is read and is not EOS someway hand it over to the processing module, which will assemble it together with the bytes read later. The advantage will be that we will ^probably^ be able to reuse a keep-alive connection. Well but this advantage seams to have a quite high price! I would vote for closing the poisoned socket and open a new one... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
