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
Received on Mon Feb 28 2011 - 22:20:29 MST
This archive was generated by hypermail 2.2.0 : Tue Mar 01 2011 - 12:00:14 MST