Re: clientReplyContext::replyStatus and proxy_keepalive

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 01 Mar 2011 11:20:23 +1300

 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