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 wrowe@apache.org 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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
|