Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Fri, 16 Dec 2005 00:18:34 -0800
From: Justin Erenkrantz <justin@erenkrantz.com>
To: dev@httpd.apache.org
Subject: Re: AW: AW: 2.2 mod_http_proxy and "partial" pages
Message-ID: <20051216081834.GU28636@scotch.ics.uci.edu>
Mail-Followup-To: Justin Erenkrantz <justin@erenkrantz.com>,
	dev@httpd.apache.org
References: 
 <F6E88684A95CDB4DBBD5B9F4C1C4B09B020EAFCB@vis01-mx02.vis.internal.vodafone.com>
 <43A1D3AD.8080609@turner.com> <43A1DC59.2030506@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43A1DC59.2030506@apache.org>
User-Agent: Mutt/1.5.11

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