Re: re initialize a namespace

2003-12-15 Thread Lincoln Stein
Thanks for the heads up. I'll fix that. Lincoln On Saturday 13 December 2003 04:28 pm, Stas Bekman wrote: > [CC'ing Lincoln on this one] > > Chris Ochs wrote: > > I am using CGI.pm with mod perl, and simply because I hate using > > $q->param('var') I use $q->import_names('CGI') so I can referenc

Re: getting any version of modperl to run

2003-12-23 Thread Lincoln Stein
I don't really maintain Apache::MP3 so much as serve as a staging point for user-contributed patch files. Send me a patch for the mod_perl 2.0 fixes, and it'll become part of the main branch. Lincoln On Monday 22 December 2003 08:53 pm, Stas Bekman wrote: > Stas Bekman wrote: > > Perrin Harkin

Re: bug with mod_perl and CGI.pm

2004-05-01 Thread Lincoln Stein
Hi Lan, Do you think this might be a bug in mod_perl 1.99X? It is the responsibility of mod_perl's CGI compatibility mode to set the CGI environment variables. It doesn't look as though CGI.pm ever tries to set CONTENT_LENGTH itself, even when running under mod_perl, but relies on mod_perl t

Re: bug with mod_perl and CGI.pm

2004-05-01 Thread Lincoln Stein
Hi Stas, Thanks for the advice. By the way, I'm currently moving all my mod_perl 1.X modules to 2.X, using the Apache::MP3 port you did a year ago as my guide. Thanks for the help! Lincoln On Saturday 01 May 2004 01:12 pm, Stas Bekman wrote: > Lincoln Stein wrote: > > Hi Lan,

Re: Apache::MP3 Stream problem

2004-06-02 Thread Lincoln Stein
My version of the port isn't quite working. Probably another couple of weekends to get all the bugs ironed out. I was really hoping to have the streaming video working fully, but maybe that'll wait for later. Lincoln On Tuesday 01 June 2004 06:12 pm, Stas Bekman wrote: > [CC'ing Lincoln] > >

Re: [patch CGI.pm] fix the read() POST requests under 'SetHandler modperl'

2003-11-05 Thread Lincoln Stein
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

Re: [patch CGI.pm] fix the read() POST requests under 'SetHandler modperl'

2003-11-05 Thread Lincoln Stein
nothing breaks. Lincoln On Monday 03 November 2003 08:08 pm, you wrote: > Lincoln, please see XXX at the end of the patch. Is it safe to assume that > read_from_client always reads from STDIN? I haven't traced all possible > calls of this method. -- Lincoln Stein [EMAIL PROTECTED]

Re: [patch CGI.pm] fix the read() POST requests under 'SetHandler modperl'

2003-11-05 Thread Lincoln Stein
X: what if $fh is not STDIN? but doesn't read_from_client, > +# imply STDIN? > +return $MOD_PERL > +? $self->r->read($$buff, $len, $offset) > +: read($fh, $$buff, $len, $offset); > } > END_OF_FUNC -- Lincoln Stein [EMAIL PROTECTED] Cold Spring Harbor Laboratory 1 Bungtown Road Cold Spring Harbor, NY 11724 (516) 367-8380 (voice) (516) 367-8389 (fax) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [patch CGI.pm] fix the read() POST requests under 'SetHandler modperl'

2003-11-05 Thread Lincoln Stein
$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 > >