Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 97718 invoked from network); 16 Dec 2005 16:31:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Dec 2005 16:31:01 -0000 Received: (qmail 81952 invoked by uid 500); 16 Dec 2005 16:30:45 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 81857 invoked by uid 500); 16 Dec 2005 16:30:45 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 81826 invoked by uid 99); 16 Dec 2005 16:30:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2005 08:30:45 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [207.155.252.31] (HELO agamemnon.cnchost.com) (207.155.252.31) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Dec 2005 08:30:44 -0800 Received: from [192.168.0.21] (c-24-13-128-132.hsd1.il.comcast.net [24.13.128.132]) by agamemnon.cnchost.com id LAA01128; Fri, 16 Dec 2005 11:30:20 -0500 (EST) [ConcentricHost SMTP Relay 1.17] Errors-To: Message-ID: <43A2EB45.9060302@rowe-clan.net> Date: Fri, 16 Dec 2005 10:28:53 -0600 From: "William A. Rowe, Jr." User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: AW: AW: 2.2 mod_http_proxy and "partial" pages References: <43A1D3AD.8080609@turner.com> <43A1DC59.2030506@apache.org> <20051216081834.GU28636@scotch.ics.uci.edu> In-Reply-To: <20051216081834.GU28636@scotch.ics.uci.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Justin Erenkrantz wrote: > On Thu, Dec 15, 2005 at 10:12:57PM +0100, Ruediger Pluem wrote: > >>I think we have to simulate to the client what happened to us on the backend: >>A broken connection. > > > I mostly agree. > > However, Roy's veto is predicated on us not doing anything that would cause > a hypothetical (*duck*) Waka protocol filter from having the underlying > connection closed. The point Roy's made is that Waka will have a 'response > abort' indicator. HTTP/1.1 doesn't - therefore, we should abort the > connection for HTTP/1.1. > > So, to respect that -1, we need to keep that in mind that we only force the > dropped connection somehow within the HTTP/1.1 logic. Or, have a clear > path for a Waka filter chain to not drop the connection - by seeing the > error bucket and morphing it into a Waka 'response abort' bucket. -- justin If we teach the HTTP/1.0 - 1.1 T-E filter to not send the 0 bucket if it sees the error bucket, and the HTTP/0.9 - 1.1 protocol filter to close the connection if it sees the error bucket and close the connection, then it should be trivial to have the waka protocol filter just keep it open flagging the last request incomplete, no? So /me concurs with your assessment. Bill