On Mon, 28 Feb 2011 14:25:10 -0700, Alex Rousskov wrote:
On 02/07/2007 05:42 PM, Alex Rousskov wrote:
clientStream_status_t
clientReplyContext::replyStatus()
{
...
if (!done) {
debug(88, 5) ("clientReplyStatus: closing, !done, but
read 0 bytes\n
return STREAM_FAILED;
}
if (!http->gotEnough()) {
debug(88, 5) ("clientReplyStatus: client didn't get all
it expected\
return STREAM_UNPLANNED_COMPLETE;
}
if (http->request->flags.proxy_keepalive) {
debug(88, 5) ("clientReplyStatus: stream complete and
can keepalive\
return STREAM_COMPLETE;
}
debug(88, 5) ("clientReplyStatus: stream was not expected
to complete!\n
return STREAM_UNPLANNED_COMPLETE;
Could somebody please explain the logic here? Specifically, I do not
understand why proxy_keepalive flag is required to get a
STREAM_COMPLETE
result. I am getting STREAM_UNPLANNED_COMPLETE (from the last return
statement) because the request apparently does not have that flag
set.
What does it mean to have a "complete stream" and why do I need a
proxy_keepalive flag with that?
Does anybody know the answer to the above? It has been bothering me
for
many years, in various contexts. Any clues?
Thank you,
Alex
Looks to me like a simple tri-state result of
success/fail-incomplete/fail-error was intended but somewhere along the
line got abused and broken.
IMHO that status should actually have a five-state:
INCOMPLETE (still processing data)
COMPLETE_SUCCESS (may keepalive, maybe cache, object fully received),
COMPLETE_UNPLANNED_END, (must close, maybe cache as a range, object
is usable but probably incomplete),
COMPLETE_FAIL (error responses generated by Squid, may keepalive, may
cache)
FAIL_ERROR (fubar, abort, must close, must not affect cache)
with keep-alive and cacheability as possible results of the status, not
determiners.
Amos
