Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <65841636-BDB3-4639-9FFD-09FE08A14AC3@jaguNET.com>
References: <8EEEDC0F-634E-459E-89EA-AC872326E3AA@jaguNET.com>
 <43A58749.3070903@apache.org>
 <FEB77F78-B64E-477D-93C5-0D2906DC204C@jaguNET.com>
 <43A5DED4.7060709@apache.org>
 <72A5F4B7-BB0B-485F-9983-F6AD0CBC73C2@jaguNET.com>
 <43A86651.9080004@turner.com> <43A87423.9000504@apache.org>
 <43B9989B.4070207@apache.org>
 <99EBAA88-116D-4757-A554-147A478CF0D8@apache.org> <43BD0789.80701@apache.org>
 <20060105115827.GA26479@redhat.com> <43BD1640.5050603@apache.org>
 <43BD7A9C.5060907@apache.org>
 <65841636-BDB3-4639-9FFD-09FE08A14AC3@jaguNET.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <927F1824-0F8C-484E-96F0-DBCAE0C61FDB@jaguNET.com>
Content-Transfer-Encoding: 7bit
From: Jim Jagielski <jim@jaguNET.com>
Subject: Re: AW: AW: AW: 2.2 mod_http_proxy and "partial" pages
Date: Fri, 6 Jan 2006 14:03:08 -0500
To: dev@httpd.apache.org


On Jan 6, 2006, at 1:47 PM, Jim Jagielski wrote:

> Still not sure why you are using a specific error detection
> filter rather than the generic one in -trunk
>
> On Jan 5, 2006, at 2:59 PM, Ruediger Pluem wrote:
>
>> @@ -146,13 +162,20 @@
>>           *   2) the trailer
>>           *   3) the end-of-chunked body CRLF
>>           *
>> -         * If there is no EOS bucket, then do nothing.
>> +         * If there is no EOS bucket, or if we had seen an error  
>> bucket with
>> +         * status HTTP_BAD_GATEWAY then do nothing. We have  
>> memorized an
>> +         * error bucket that we had seen in the filter context.
>> +         * The error bucket with status HTTP_BAD_GATEWAY  
>> indicates that the
>> +         * connection to the backend (mod_proxy) broke in the  
>> middle of the
>> +         * response. In order to signal the client that something  
>> went wrong
>> +         * we do not create the last-chunk marker and set c- 
>> >keepalive to
>> +         * AP_CONN_CLOSE in the core output filter.
>>           *
>>           * XXX: it would be nice to combine this with the end-of- 
>> chunk
>>           * marker above, but this is a bit more straight-forward for
>>           * now.
>>           */
>> -        if (eos != NULL) {
>> +        if (eos && !f->ctx) {
>
> Code logic doesn't match comment.
>

I should clarify that: when the comment says "or" yet the
code does an "and" then it causes undue confusion, even
if the 2 do sync up.