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 15:05 ------- (In reply to comment #4) > That's interesting but not conclusive; it could just mean the proxy has failed > to consume multiple 100 responses from the previous request on that connection > (also quite valid). ethereal/tcpdump (with -s0!) captures for both > client/proxy Ah OK that trace has surely also an earlier phase which looks like 71228 httpd CALL read(0x18,0x81f4028,0x1f40) 71228 httpd GIO fd 24 read 1658 bytes "HTTP/1.1 200 OK\r ... ... 71228 httpd RET read 1658/0x67a this is the last response from backend before the next POST mentioned in the trace in previous comment. I think there is no way of leaving some content selectively in the TCP stack. And there is only one place in the code proxy_http.c where one byte read is performed... > and proxy/backend connection would be useful if you're sure that the server is > really issuing a 100 *after* a non-1xx response. I am quite sure that the server does this! I had also the tcpdump traces for this scenario. Reproducing this problem again is a quite time consuming task, however I'll attach the trace results when I come up with this test. -- 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]
