Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 13174 invoked by uid 500); 31 Mar 2001 20:18:59 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 13163 invoked from network); 31 Mar 2001 20:18:59 -0000 From: TOKILEY@aol.com Message-ID: Date: Sat, 31 Mar 2001 15:18:30 EST Subject: Re: [PATCH] mod_proxy Keepalives To: new-httpd@apache.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 16-bit for Windows sub 86 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N In a message dated 01-03-31 14:11:19 EST, Ryan writes. > Not only is buff.c gone, but as Bill Stoddard has pointed out on > new-httpd, the modifications to Buff.c for 1.3 were minimal, it is not a > full re-write. > > Ryan As long as the conn->proxy thing is the 'other' side of the conversation and not a dupe of the client it shouldn't matter and my concerns are moot. The IBMHTTP conn_rec is still removing some of the WIN32 stuff, though, isn't it? My real point was that if new conn_rec(s) of any description are appearing somewhere in standard Apache then there is more chance for breakage in IBMHTTPD because their conn_rec is not the same. If a module is written to reference things that are missing from conn_rec under IBMHTTPD then that module is going to need 'ifdef IBMHTTPD' stuff in it and will need to know what is missing and why. It hasn't really been an issue so far except for a few transport layer modules I know of... but it could be. If the changes to conn_rec for IBM_HTTPD are trivial then why not get them posted up as a patch for the real Apache conn_rec so there is no mystery for module writers and the chance they might refer to things that aren't going to be there for IBMHTTPD compile of Apache? Kevin Kiley