Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <476641DD.4010105@sneakemail.com>
Date: Mon, 17 Dec 2007 10:31:09 +0100
From: =?UTF-8?B?UGV0ZXIgVmFsZGVtYXIgTcO4cmNo?= <swp5jhu02@sneakemail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: dev@perl.apache.org, modperl@perl.apache.org
CC: Dmitry Karasik <dmitry@karasik.eu.org>
Subject: Re: [mp2] mod_perl closes apache's stdin and/or stdout
References: <20070925140658.GA77686@tetsuo.karasik.eu.org>
In-Reply-To: <20070925140658.GA77686@tetsuo.karasik.eu.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

Dmitry Karasik dmitry-at-karasik.eu.org wrote:
> mod_perl during the initialization process closes file descriptor 0,
> and frees it for further reuse in other processes.  Therefore, any cgi =
script
> executing after mod_perl is initialized, and in the same process tree, =
will
> have file descriptor 0 closed. The concrete example where this behavior=
 leads
> to impossibility of processing POST requests is reported earlier and is=
 located
> at
>=20
>   http://marc.info/?l=3Dapache-modperl&m=3D119062450730646&w=3D2

Dmitry's patch from  Sep 25, 2007=20
http://www.gossamer-threads.com/lists/modperl/modperl/94912 has still=20
not been applied to SVN. May I humbly ask that this patch is applied?

On the dev list=20
http://marc.info/?l=3Dapache-modperl-dev&m=3D119125026607247&w=3D2 it see=
ms=20
that whether or not this really is a bug is drawn into question. I can=20
confirm that it, really, really is a bug!

I'm now getting emails from others experiencing the same problem,=20
querying for a solution. Dmitry's patch fixes our problem. I'm now=20
forwarding links to the patch to other users. Wouldn't it be easier to=20
have this or another patch applied or another that also fixes the problem=
???

The patch didn't apply completely cleanly here against HEAD, but this=20
one does ( also at http://demo.capmon.dk/~pvm/modperl_io.patch ) :

~/mod_perl-2.0/src/modules/perl> svn diff
Index: modperl_io.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- modperl_io.c        (revision 604795)
+++ modperl_io.c        (working copy)
@@ -116,6 +116,7 @@
      /* if STDIN is open, dup it, to be restored at the end of response =
*/
      if (handle && SvTYPE(handle) =3D=3D SVt_PVGV &&
          IoTYPE(GvIO(handle)) !=3D IoTYPE_CLOSED) {
+       IO * io =3D GvIO(handle);
          handle_save =3D gv_fetchpv(Perl_form(aTHX_
                                             "Apache2::RequestIO::_GEN_%l=
d",
                                             (long)PL_gensym++),
@@ -128,6 +129,17 @@
              Perl_croak(aTHX_ "Failed to dup STDIN: %" SVf, get_sv("!",=20
TRUE));
          }

+       /* In mixed environment of mod_perl and cgi scripts, cgi
+        * scripts may read content of POST requests off
+        * STDIN. do_close() calls actual close(0), freeing the
+        * descriptor 0 for reuse, and creating havoc for anyone
+        * reading from file descriptor 0.  This hack changes the IO
+        * type to IoTYPE_STD, because do_close() does not call
+        * underlying close() on IO handles of these types, but does
+        * free the associated resources. */
+        if ( IoIFP(io) && PerlIO_fileno(IoIFP(io)) =3D=3D 0)
+           IoTYPE(io) =3D IoTYPE_STD;
+
          /* similar to PerlIO::scalar, the PerlIO::Apache layer doesn't
           * have file descriptors, so STDIN must be closed before it can
           * be reopened */

Thanks,

Peter
--=20
Peter Valdemar M=C3=B8rch
http://www.morch.com