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 17:50 ------- Joe saiz "It's not *after* the last request, it's *before* the next request; it is legitimate behaviour..." Ah ha :) However; it's invalid prior to a REQUEST being sent to the origin server, no? It would only be valid after the 2nd request was submitted (e.g. HEAD - test resource, POST - transmit resource). So if we did a look-ahead for any bytes to be read from the backend stream before we sent the subsequent request, and saw lingering bytes (other than perhaps redundant CR/LF pairs), then we could safely terminate the backend proxy, presume it is poisioned, and begin the next request on another, new connection. If there were no bytes to be read from the backend, after we consume a few extra/redundant CR/LF gaps, then we would trust the backend had not split a response. The 100 responses are only valid between the moment a request received, and the final result code has been sent. 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. -- 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]
