- Original Message -
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "mod_perl Mailing List" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; "Issac Goldstand" <[EMAIL PROTECTED]>
Sent: Sunday, November 09,
Lincoln Stein wrote:
Hi all,
Here's an alpha3 version to test. After much arguing with Stas, I can't find
a single case in which the read_from_client() ever gets passed a non-STDIN
filehandle. I'm beginning to wonder if this was put there to allow for
debugging of the file upload function, or
Lincoln Stein wrote:
$q = CGI->new(\*FH);
I've read the source code of init() and it seems that if you pass the
filehandle in this way, it never reaches read_from_client as you use this fh
to populate $query_string right there in init().
The only place it's used is in:
$fh = to_fileha
Lincoln Stein wrote:
What it does now (in the version I sent out this AM) is to check whether the
filehandle is STDIN. If not, it reverts to the old code. Otherwise it uses
yours. Sound OK to you?
No, this doesn't work:
$fh eq \*STDIN
because it can be:
GLOB(0x86af9d8)
main::STDIN
STDIN
th
$q = CGI->new(\*FH);
Lincoln
On Wednesday 05 November 2003 02:50 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> > No, it made sense for the fastCGI and original Apache::Request modules.
> > The CGI state data potentially comes from many sources: sometimes from
> > stdin and sometimes from mod_p
OK, I've traced through stuff. The current proposed fix will break the
ability to read and write CGI state to temporary files, database handles, etc
when operating under mod_perl. Possibly some of the persistent state engines
use this, but I think I'll leave it as a known bug.
Lincoln
On Mon
Hi Stas,
Actually the read_from_client method() is supposed to be overridden in
subclasses so that it can read directly from mod_perl, fastCGI, etc. The
thing's a mess at this point, and so I'm going to close my eyes, fold in
Scott's changes, release it to the world, and hope nothing breaks.
What it does now (in the version I sent out this AM) is to check whether the
filehandle is STDIN. If not, it reverts to the old code. Otherwise it uses
yours. Sound OK to you?
Lincoln
On Wednesday 05 November 2003 03:05 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> >>Lincoln Stein wrote:
Lincoln Stein wrote:
Lincoln Stein wrote:
No, it made sense for the fastCGI and original Apache::Request modules.
The CGI state data potentially comes from many sources: sometimes from
stdin and sometimes from mod_perl.
That part is clear, and we are good here. But you said something different.
Lincoln Stein wrote:
Hi Folks,
Please test out the following alpha release of CGI.pm 3.01. Things that need
to be examined:
- regularly POST
- multipart POST
- file upload
These were tested with only with mod_perl 2 with our own tests.
- saving state to files/pipes and
Lincoln Stein wrote:
No, it made sense for the fastCGI and original Apache::Request modules. The
CGI state data potentially comes from many sources: sometimes from stdin and
sometimes from mod_perl.
That part is clear, and we are good here. But you said something different.
You said that read_f
Lincoln Stein wrote:
OK, I've traced through stuff. The current proposed fix will break the
ability to read and write CGI state to temporary files, database handles, etc
when operating under mod_perl. Possibly some of the persistent state engines
use this, but I think I'll leave it as a known
gt; To: Stas Bekman; mod_perl Mailing List; Scott Beuker
> Subject: Re: [patch CGI.pm] fix the read() POST requests under
> 'SetHandler modperl'
>
>
> Hi Folks,
>
> Please test out the following alpha release of CGI.pm 3.01.
> Things that need
> to be examined
Scott Beuker wrote:
I've reverted and patched, looks good. No issues so far as I can
see, the clients that were affected before are still working fine.
Thanks Scott!
I've added several tests to the mod_perl 2 test suite as well and it looks
good too. Now awaiting feedback from Lincoln.
_
I've reverted and patched, looks good. No issues so far as I can
see, the clients that were affected before are still working fine.
Thanks,
Scott Beuker
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: November 3, 2003 6:08 PM
> To: mod_perl Mailing List; Scott B
15 matches
Mail list logo
