Received: by taz.hyperreal.com (8.7.5/V2.0) id GAA19896; Fri, 23 Aug 1996 06:39:09 -0700 (PDT) Received: from shado.jaguNET.com by taz.hyperreal.com (8.7.5/V2.0) with ESMTP id GAA19862; Fri, 23 Aug 1996 06:39:03 -0700 (PDT) Received: (from jim@localhost) by shado.jaguNET.com (8.7.5/jag-2.2) id JAA03022 for new-httpd@hyperreal.com; Fri, 23 Aug 1996 09:39:02 -0400 (EDT) From: Jim Jagielski Message-Id: <199608231339.JAA03022@shado.jaguNET.com> Subject: Re: nph and lingering_close To: new-httpd@hyperreal.com Date: Fri, 23 Aug 1996 09:39:02 -0400 (EDT) In-Reply-To: from "Alexei Kosut" at Aug 22, 96 03:12:19 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Alexei Kosut wrote: > > Okay... > > I've spent the last few hours trying to figure out why nph scripts don't > work with the lingering close code. It boils down to something like this: > > When mod_cgi starts an nph script, it duplicates the client connection fd, > and passes it to the CGI script as stdout. Because there are two handles > to this fd, when bclose() closes its, it doesn't actually close the > socket because the CGI script still has one open. The connection stays > open until the CGI script exits. However, lingering_close() uses > shutdown(), which closes the socket right away, even though the CGI script > still has a handle open to it. > > So... the fix? Well, a simple one is to simply make mod_cgi wait until the > CGI script finishes before passing control back to Apache. This way you > sidestep the problem entirely. Patch follows: > Nice and elegant. Works like a charm too! +1 -- Jim Jagielski << jim@jaguNET.com >> | "There is a time for laughing, ** jaguNET Access Services ** | and a time for not laughing, Email: info@jaguNET.com | and this is not one of them" ++ http://www.jaguNET.com/ +++ Voice/Fax: 410-931-3157 ++