Re: re initialize a namespace
Hi!
On Fri, Dec 12, 2003 at 08:32:30PM -0800, 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 reference the post
> variables as $CGI::var. CGI.pm does not clear this namespace and I am not
> sure of the best way to clear an entire namespace. Any ideas?
IMO you're far better of adapting to the $q->param syntax than to import a
whole lot of symbols (let alone deleting them after use).
Additionally, you could switch to Apache::Request, which is much faster than
CGI.pm and uses nearly the same syntax.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] CGI.pm patch
Michael Peppler wrote: I ran into the same (or a similar) problem that Scott Beuker reported with CGI.pm truncating POST content in an mp2 setup. In my case the POST was truncated at around 7500 bytes. A check with tcpdump shows that the entire POST is correctly sent to apache. I started by upgrading CGI.pm to the latest release (3.01), but that didn't fix it. Yes, but you also need the latest mp2. There was a bug both in mp2 and CGI.pm. Both fixed in the latest versions. modperl-2.0/Changes: =item 1.99_11 - November 10, 2003 [...] rewrite $r->read() and perlio read functions to use the same function, which completely satisfies the read request if possible, on the way getting rid of get_client_block and its supporting functions which have problems and will most likely will be removed from the httpd-API in the future. Directly manipulate bucket brigades instead. [Stas] __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [Fun] telecommuting job
Slava Bizyayev wrote: -Original Message- From: Slava Bizyayev [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2003 3:55 PM To: Laurie Roth Subject: RE: Sr. Perl Developer Are you idiot? I know some recruiters appear complete and utter morons however if you want a decent job you will probably need thier help, if only to ensure your CV is good enough to pass the first hurdles. He is right in that technical skills are simply not enough and if this was truly your reply to what appears to be a honest mistake, then you were quite rightly excluded from the selection process. On the other hand dsninc.com does have a somewhat tarnished reputation. It is not an agency I would ever consider using... Jacqui -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: re initialize a namespace
[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 reference the post
variables as $CGI::var. CGI.pm does not clear this namespace and I am not
sure of the best way to clear an entire namespace. Any ideas?
CGI.pm does cleanup imported vars (I don't know why doesn't it work for you):
sub import_names {
my($self,$namespace,$delete) = self_or_default(@_);
$namespace = 'Q' unless defined($namespace);
die "Can't import names into \"main\"\n" if \%{"${namespace}::"} == \%::;
if ($delete || $MOD_PERL || exists $ENV{'FCGI_ROLE'}) {
# can anyone find an easier way to do this?
foreach (keys %{"${namespace}::"}) {
local *symbol = "${namespace}::${_}";
undef $symbol;
undef @symbol;
undef %symbol;
}
}
my($param,@value,$var);
foreach $param ($self->param) {
# protect against silly names
($var = $param)=~tr/a-zA-Z0-9_/_/c;
$var =~ s/^(?=\d)/_/;
local *symbol = "${namespace}::$var";
@value = $self->param($param);
@symbol = @value;
$symbol = $value[0];
}
}
Though looking at your example, where you use $q->import_names('CGI') instead
of the default 'Q', it seems to be a bad idea, since CGI.pm blindly nukes all
vars in any given namespace, including variables which weren't imported. Since
you have called $q->import_names('CGI') it's going to nuke things like
$CGI::VERSION and many other CGI:: variables that it needs to operate properly.
I think CGI.pm needs to maintain a global list of vars that it has imported
and only undef them. Even that's troublesome - if a malicious user changes the
query string to include VERSION=234, it'll override the real $CGI::VERSION.
Same goes for many other internal variables. It's quite possible that some can
find security issues with this functionality.
At the very least CGI.pm, shouldn't allow using 'CGI' as the namespace for
importing names.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [OT] [mod_perl] [Fun] telecommuting job
Slava Bizyayev wrote: On Fri, 2003-12-12 at 13:11, Chris Shiflett wrote: I'm curious now. You posted an off-topic message on a mod_perl mailing list that: 1. Demonstrated how rude you were to another person. 2. Revealed private correspondence on a public mailing list. Hear hear - my only thought was that Slava was faking his email address and personality to try and disparage a real Slava. We all make mistakes and it is far better to just admit to them and apologise. Trying to publically ridicule someone for what seems a quite courteous if curt response is bad enough. Doing it here where it will be hopefully archived forever is just plain insane. Trying to dig yourself out of this gaffe is just making things worse. Remember that quite a few folks on this list are people who vet perl candidates for thier own company and for others (clients). You have just ruined any chance of getting anywhere with any of them... Not what I would call a good career move :-) My advice would be to apologise to all concerned and never to 1. or 2. again... Jacqui -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
mod_perl non-configurability ???
Any Debian users here? # sudo /etc/init.d/apache restart Reloading apache modules/etc/init.d/apache: line 70: 19518 Segmentation fault start-stop-daemon --start --pidfile $PIDFILE --exec $DAEMON failed # COLUMNS=120 dpkg -l '*apache*' | grep ^i | cut -c 0-50 ii apache 1.3.27.0-2 ii apache-common1.3.27.0-2 ii libapache-mod-jk 3.3.1a-1 ii libapache-mod-perl 1.27-4 ii libapache-mod-perl-doc 1.29.0.1-1cvs20031206 ii libapache-mod-webapp 1.3.0-1.0.ipv6.r1 # ls -l /usr/lib/apache/1.3/mod_perl.so -rw-r--r--1 root root 327584 Apr 14 2003 /usr/lib/apache/1.3/mod_perl.so # grep -i perl /etc/apache/httpd.conf | grep mod LoadModule perl_module /usr/lib/apache/1.3/mod_perl.so # dpkg -L libapache-mod-perl | grep -i read | sort /usr/share/doc/libapache-mod-perl/README.gz /usr/share/doc/libapache-mod-perl/examples/README Apache works just fine *without* that LoadModule line, and no other changes to httpd.conf repeatedly result in this error. I cannot find a README.Debian, nor have I found any manual instructions for configuring httpd.conf. I _did_ manually add the LoadModule line, since I have had to do that before on other systems. mod_php install offers to do that automatically; but, mod_perl installation offered no such assistance. What do you think? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
