[26980] in Perl-Users-Digest
Perl-Users Digest, Issue: 8925 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 6 14:05:49 2006
Date: Mon, 6 Feb 2006 11:05:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 6 Feb 2006 Volume: 10 Number: 8925
Today's topics:
how do you interpoplate against units in a here-doc? <g_m@remove-comcast.net>
Re: Morse code audio playout? <zentara@highstream.net>
New CPAN module integration of Authcookie with PAM avandanaa@hotmail.com
Obscure utf8/"panic: malloc" bug (II) <socyl@987jk.com.invalid>
Re: Question about abuse of a CGI script <matthew.garrish@sympatico.ca>
Re: Question about abuse of a CGI script <news@chaos-net.de>
Re: Question about abuse of a CGI script <news@chaos-net.de>
Re: Question about abuse of a CGI script <1usa@llenroc.ude.invalid>
Re: Question about abuse of a CGI script <ben.usenet@bsb.me.uk>
Re: Question about abuse of a CGI script <news@chaos-net.de>
Re: SOAP::Lite example meets http server 500 error? <1usa@llenroc.ude.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 6 Feb 2006 12:30:31 -0500
From: "~greg" <g_m@remove-comcast.net>
Subject: how do you interpoplate against units in a here-doc?
Message-Id: <_b2dnVNUpNkwGnreRVn-vQ@comcast.com>
problem is something like this:
var $WIDTH = 10;
print OUT <<__;
...
width: $WIDTHpx;
...
__
to print
...
width: 10px
...
What can be insert between the "$WIDTH" and the "px to make this work?
(don't want to break up the here-doc.
Thought of using $X = "" but that obviously doesn't work.
If there is a special variable (like $_)
that's == "", that might work.)
------------------------------
Date: Mon, 06 Feb 2006 14:04:19 GMT
From: zentara <zentara@highstream.net>
Subject: Re: Morse code audio playout?
Message-Id: <9oleu1djaorccded7smtnnv1mtg9prbppq@4ax.com>
On Sun, 05 Feb 2006 17:27:36 -0600, "Gan Uesli Starling"
<gan@starling.us> wrote:
>My attachment did not attach. Or at least I did not see it when I
>checked my post. Sorry, too, about the non-wrap. Anyway, rather
>than attach my code. If you like, it is on-line here:
>
>http://starling.ws/morse
Hi, it works. :-)
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
------------------------------
Date: Mon, 6 Feb 2006 11:29:03 GMT
From: avandanaa@hotmail.com
Subject: New CPAN module integration of Authcookie with PAM
Message-Id: <Iu9t5E.1AK8@zorch.sf-bay.org>
Hello,
I have written a new module AuthCookiePAM available in CPAN under
author :AWA
(authors/id/A/AW/AWA/AuthCookiePAM.pm)
This module has been developed using AuthCookieDBI.
I am new to contributing sources into CPAN, so please do post me your
suggestions reagrding the level of detail I should include in the
announcements.
Kind Regards
Vandana
------------------------------
Date: Mon, 6 Feb 2006 16:27:53 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Obscure utf8/"panic: malloc" bug (II)
Message-Id: <ds7te9$265$1@reader2.panix.com>
OK, I've reduced to a small script the code necessary to trigger
the bug mentioned in the subject line. Unfortunately, this is very
much of a heisenbug. I found that even changes that should not
affect the program (such adding a blank line or a comment to the
source, or changing the names of variables) would cause the bug to
manifest itself differently, and sometimes even disappear.
Here's the script:
# bug.pl
use strict;
use warnings FATAL => 'all';
use XML::Simple;
use DBI;
my $config = XMLin( <<'EOXML',
<?xml version="1.0"?>
<!DOCTYPE Foo> <Foo> <Bar instanceName="test" /> </Foo>
EOXML
keyattr => []
);
my $h = $config->{ Bar };
my $dbname = $h->{ instanceName };
eval {
DBI->connect(
"dbi:mysql:database=$dbname;host=localhost;port=3306",
'anonymous',
'',
{ InactiveDestroy => 1 }
);
};
my $error = $@;
for my $mod_file ( sort keys %INC ) {
my ( $package, $version ) = ( $mod_file, '???' );
if ( $mod_file =~ s/\.pm$// ) {
( $package = $mod_file ) =~ s#[/\\]#::#g;
$version = eval( '$' . $package . '::VERSION' ) || '???';
}
print "$package $version\n";
}
print "\n$error\n" if $error;
__END__
Supposing one calls the script bug.pl, and one runs it under the
debugger like this
% perl -d bug.pl
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(bug.pl:8): my $config = XMLin( <<'EOXML',
main::(bug.pl:9): <?xml version="1.0"?>
main::(bug.pl:10): <!DOCTYPE Foo> <Foo> <Bar instanceName="test" /> </Foo>
main::(bug.pl:11): EOXML
main::(bug.pl:12): keyattr => []
main::(bug.pl:13): );
DB<1> c
...the script will print the versions of the modules listed in %INC,
and then will print the value that $@ had right after the eval.
On my system, when all the planets are properly aligned, this value is
panic: malloc at /usr/lib/perl5/vendor_perl/5.8.6/i586-linux-thread-multi/DBD/mysql.pm line 49.
Below I give the full output of the script, plus the outputs of
perl -V, uname -ar, and cat ~/.perldb.
kj
% perl -d bug.pl
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(bug.pl:8): my $config = XMLin( <<'EOXML',
main::(bug.pl:9): <?xml version="1.0"?>
main::(bug.pl:10): <!DOCTYPE Foo> <Foo> <Bar instanceName="test" /> </Foo>
main::(bug.pl:11): EOXML
main::(bug.pl:12): keyattr => []
main::(bug.pl:13): );
DB<1> c
/home/jones/.perldb ???
AutoLoader 5.60
Carp 1.03
Carp::Heavy ???
Config ???
DBD::mysql 3.0002
DBI 1.50
DynaLoader 1.05
Exporter 5.58
Exporter::Heavy 5.58
File::Basename 2.73
File::Spec 3.16
File::Spec::Unix 1.5
IO 1.21
IO::Handle 1.24
List::Util 1.14
Scalar::Util 1.14
SelectSaver 1.00
SelfLoader 1.0904
Symbol 1.05
Term::Cap 1.09
Term::ReadKey 2.30
Term::ReadLine 1.01
Term::ReadLine::Perl 0.99
Term::ReadLine::readline ???
XML::NamespaceSupport 1.09
XML::Parser 2.34
XML::Parser::Expat 2.34
XML::SAX 0.13
XML::SAX::Base 1.04
XML::SAX::Exception 1.01
XML::SAX::Expat 0.37
XML::SAX::ParserFactory 1.01
XML::Simple 2.14
XSLoader 0.02
attributes 0.06
base 2.06
constant 1.04
overload 1.02
perl5db.pl ???
re 0.04
strict 1.03
unicore/Canonical.pl ???
unicore/Exact.pl ???
unicore/PVA.pl ???
unicore/To/Fold.pl ???
unicore/lib/gc_sc/SpacePer.pl ???
unicore/lib/gc_sc/Word.pl ???
utf8 1.04
utf8_heavy.pl ???
vars 1.01
warnings 1.03
warnings::register 1.00
panic: malloc at /usr/lib/perl5/vendor_perl/5.8.6/i586-linux-thread-multi/DBD/mysql.pm
Debugged program terminated. Use q to quit or R to restart,
use O inhibit_exit to avoid stopping after program termination,
h q, h R or h O to get additional info.
DB<1> q
% perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=linux, osvers=2.6.9, archname=i586-linux-thread-multi
uname='linux g226 2.6.9 #1 smp tue jun 28 14:58:56 utc 2005 i686 i686 i386 gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -g -Wall -pipe'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall -g -Wall -pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe'
ccversion='', gccversion='3.3.5 20050117 (prerelease) (SUSE Linux)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/local/lib
libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962
Built under linux
Compiled at Dec 17 2005 03:23:29
%ENV:
PERL5LIB="/home/jones/local/lib/perl5"
PERL_RL="Perl"
@INC:
/home/jones/local/lib/perl5/5.8.6/i586-linux-thread-multi
/home/jones/local/lib/perl5/5.8.6
/home/jones/local/lib/perl5/i586-linux-thread-multi
/home/jones/local/lib/perl5
/usr/lib/perl5/5.8.6/i586-linux-thread-multi
/usr/lib/perl5/5.8.6
/usr/lib/perl5/site_perl/5.8.6/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.6/i586-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl
.
% uname -ar
Linux llama 2.6.11.4-21.10-smp #1 SMP Tue Nov 29 14:32:49 UTC 2005 i686 i686 i386 GNU/Linux
% cat ~/.perldb
parse_options("PrintRet=0");
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Mon, 6 Feb 2006 07:20:53 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Question about abuse of a CGI script
Message-Id: <DaHFf.7989$1e5.190571@news20.bellglobal.com>
"Martin Kissner" <news@chaos-net.de> wrote in message
news:slrndudgrd.s8a.news@maki.homeunix.net...
> Gunnar Hjalmarsson wrote :
>> Martin Kissner wrote:
>>> Gunnar Hjalmarsson wrote :
>>>>Martin Kissner wrote:
>>>>>Am I right if I suppose that such a script contacts the form on my
>>>>>website, fills in some values into my fields and then submits the form?
>>>>
>>>>No. Such a script doesn't care about your form. It passes the values
>>>>directly to your script.
>>>
>>> In this case it must be different.
>>> I renamed the form but not the script.
>>> Then I duplicated the form, changed the action in the <form> tag and
>>> saved it under the original name.
>>> The new action script only counts the hits by saving the IP addresses
>>> used by
>>> the spammer but doesn't send any mails. It doesn#T even look at the
>>> fields.
>>
>> The spammer needs to know what to submit and whereto, and that info he
>> reasonably grabs from your form. Then, when actually abusing your
>> script, he most likely bypasses your form.
>>
> Okay; wherto would be the script, right?
>
> but how can he find out about the script's name? The script lies in
> /cgi-bin/ and the scripts name does not appear in the form or any other
> file which is accessible directly via HTTP. The action in the html form
> is a html filename which is redirected via .htaccess/mod_rewrite to the
> cgi script. This filename I have changed.
>
But a request is a request, whether it comes from a browser or is created
manually by a program. The spammer's request gets forwarded the same way the
browsers request gets forwarded. You should really take some time to look
over the LWP modules and what they can do (specifically posting data), as
well as read up on how http requests work. Without more fundamentals in how
the Web operates, you'll have a very hard time writing secure scripts.
Matt
------------------------------
Date: Mon, 6 Feb 2006 14:13:35 +0100
From: Martin Kissner <news@chaos-net.de>
Subject: Re: Question about abuse of a CGI script
Message-Id: <slrndueirv.14d.news@maki.homeunix.net>
A. Sinan Unur wrote :
> Martin Kissner <news@chaos-net.de> wrote in
> news:slrndudgrd.s8a.news@maki.homeunix.net:
>
>> Gunnar Hjalmarsson wrote :
>>> Martin Kissner wrote:
>>>> Gunnar Hjalmarsson wrote :
>>> The spammer needs to know what to submit and whereto, and that info
>>> he reasonably grabs from your form. Then, when actually abusing your
>>> script, he most likely bypasses your form.
>>>
>> Okay; wherto would be the script, right?
>
> "Where to" is whatever is in the action attribute of the form you are
> using.
Then it is a nonexisting html filename he tries to access now which is
not processed by the script in the way he relies on.
>> but how can he find out about the script's name? The script lies in
>> /cgi-bin/ and the scripts name does not appear in the form or any
>> other file which is accessible directly via HTTP. The action in the
>> html form is a html filename which is redirected via
>> .htaccess/mod_rewrite to the cgi script. This filename I have
>> changed.
>>
>> Is there a chance somone could find out where to submit the data?
>
> I don't know what you are talking about, but that's irrelevant. Web
> server configuration is off-topic here (well, so was CGI. Forgive me for
> I have sinned).
Forgive me, too. I have asked about how my perl CGI skript, which is
running on a web server, could have been hacked by a spammer in a perl
newsgroup.
But wait - I have decided to ask here because I was
interested in what _perl_code_ the spammer might have passed to my
_perl_script_. My original question was not about CGI and and not about
web server configuration but about perl code.
But you are right. The last question is off-topic here. I should have
asked it in a web server related group.
Best regards
Martin
btw: I have tested the script you gave me in the other post on a FreeBSD
machine. There I get the same result as you do (Bcc addresses in a
newline).
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
------------------------------
Date: Mon, 6 Feb 2006 14:55:01 +0100
From: Martin Kissner <news@chaos-net.de>
Subject: Re: Question about abuse of a CGI script
Message-Id: <slrnduel9l.14d.news@maki.homeunix.net>
Matt Garrish wrote :
>
> "Martin Kissner" <news@chaos-net.de> wrote in message
> news:slrndudgrd.s8a.news@maki.homeunix.net...
>> Gunnar Hjalmarsson wrote :
>>> Martin Kissner wrote:
>>>> Gunnar Hjalmarsson wrote :
>>> The spammer needs to know what to submit and whereto, and that info he
>>> reasonably grabs from your form. Then, when actually abusing your
>>> script, he most likely bypasses your form.
>>>
>> Okay; wherto would be the script, right?
>>
>> but how can he find out about the script's name? The script lies in
>> /cgi-bin/ and the scripts name does not appear in the form or any other
>> file which is accessible directly via HTTP. The action in the html form
>> is a html filename which is redirected via .htaccess/mod_rewrite to the
>> cgi script. This filename I have changed.
>>
>
> But a request is a request, whether it comes from a browser or is created
> manually by a program. The spammer's request gets forwarded the same way the
> browsers request gets forwarded.
Yes, I know.
But doesn't the program of the spammer have to passuse an URI as the browser
does?
And now he keeps on passing an URI which doesn't make my script send mail.
The spammer requests a file on the webserver and sends some data to its
stdin. The filename (which is part of the URI) and the data are passed
to my cgi script but when the script "sees" the URI, it refuses to read
the data but only hits a counter and exits. In my case I don't think
the spammer accesses the script itself and if he does, he has to pass
the URI which triggers the script to send mail.
Isn't this right?
If it is, I think changing the filename which makes the script send mail
was not that bad and also I have changed the script to take a closer
look at the data provided by the user (for the new filename in the form
action attribute).
> You should really take some time to look over the LWP modules and what
> they can do (specifically posting data), as well as read up on how
> http requests work. Without more fundamentals in how the Web operates,
> you'll have a very hard time writing secure scripts.
Yes, thank you. I have bought the book "Network Programming with perl"
by Lincoln Stein, which I think is a good choice.
Best regards
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
------------------------------
Date: Mon, 6 Feb 2006 15:18:17 +0000 (UTC)
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Question about abuse of a CGI script
Message-Id: <Xns976268D27B92Basu1cornelledu@132.236.56.8>
Martin Kissner <news@chaos-net.de> wrote in
news:slrndueirv.14d.news@maki.homeunix.net:
> A. Sinan Unur wrote :
>> Martin Kissner <news@chaos-net.de> wrote in
>> news:slrndudgrd.s8a.news@maki.homeunix.net:
>>
>>> Gunnar Hjalmarsson wrote :
>>>> Martin Kissner wrote:
>>>>> Gunnar Hjalmarsson wrote :
>
>>>> The spammer needs to know what to submit and whereto, and that info
>>>> he reasonably grabs from your form. Then, when actually abusing
>>>> your script, he most likely bypasses your form.
>>>>
>>> Okay; wherto would be the script, right?
>>
>> "Where to" is whatever is in the action attribute of the form you are
>> using.
>
> Then it is a nonexisting html filename he tries to access now which is
> not processed by the script in the way he relies on.
That sentence makes no sense. If a visitor can submit the form using a
web browser, then a simple script using LWP, or the command line wget
program can also submit to the same target specified in the action
attribute of the form element you are using.
Your confusion arises from the fact that you don't seem to understand how
HTTP and CGI work, and you confuse the issue by adding in all sorts of
web server configuration issues.
In summary:
Q1) How do I save the full query submitted to my CGI script.
A) Look into methods provided for this purpose by CGI.pm and CGI::Minimal
Q2) How do I prevent a spammer from using my script to send email to
thousands of people?
A) The safest way is to prevent a web site visitor from being able to
enter any email address. Short of that, look at CGI::ContactForm to see
how to make sure the submitted parameter only contains a single email
address.
There seems to be nothing else that is remotely Perl related to discuss.
Sinan
------------------------------
Date: Mon, 06 Feb 2006 16:30:38 +0000
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Question about abuse of a CGI script
Message-Id: <pan.2006.02.06.16.30.38.282497@bsb.me.uk>
On Sun, 05 Feb 2006 14:42:08 -0500, John W. Kennedy wrote:
> Martin Kissner wrote:
>> Now the script was abused by a spammer who sent at least 6000 (probably
>> far more) spam emails.
>
> A device that has worked for me to foil robot spammers is simply to leave
> the submit button out of the HTML and create it instead at onload time,
> using JavaScript. It won't stop a human, but generally stymies robots.
This has a couple of down sides: First, it only works while few people use
it. When is becomes the norm, robots will have to incorporate a JS engine
and the benefit will be lost. Second, you inconvenience users who can't
(or prefer not) to use JS. This inconvenience could be argued about were
it not for the fact the form scripts can be made robot safe by
other means -- careful coding.
--
Ben.
------------------------------
Date: Mon, 6 Feb 2006 17:54:14 +0100
From: Martin Kissner <news@chaos-net.de>
Subject: Re: Question about abuse of a CGI script
Message-Id: <slrnduevpm.170.news@maki.homeunix.net>
A. Sinan Unur wrote :
> Martin Kissner <news@chaos-net.de> wrote in
> news:slrndueirv.14d.news@maki.homeunix.net:
>
>> A. Sinan Unur wrote :
>>> Martin Kissner <news@chaos-net.de> wrote in
>>> news:slrndudgrd.s8a.news@maki.homeunix.net:
>>>
>>>> Gunnar Hjalmarsson wrote :
>>>>> Martin Kissner wrote:
>>>>>> Gunnar Hjalmarsson wrote :
>>
>>>>> The spammer needs to know what to submit and whereto, and that info
>>>>> he reasonably grabs from your form. Then, when actually abusing
>>>>> your script, he most likely bypasses your form.
>>>>>
>>>> Okay; wherto would be the script, right?
>>>
>>> "Where to" is whatever is in the action attribute of the form you are
>>> using.
>>
>> Then it is a nonexisting html filename he tries to access now which is
>> not processed by the script in the way he relies on.
>
> That sentence makes no sense. If a visitor can submit the form using a
> web browser, then a simple script using LWP, or the command line wget
> program can also submit to the same target specified in the action
> attribute of the form element you are using.
>
> Your confusion arises from the fact that you don't seem to understand how
> HTTP and CGI work, and you confuse the issue by adding in all sorts of
> web server configuration issues.
No, I don't think so. Maybe I can not make myself understood because of
my bad English. Maybe I should provide specific filenames to make this
clear.
Before the spammer's attack the target specified in the action attribute
of the form element has been "/emailantwort.html". This target was
redirected to "/cgi-bin/script.cgi".
"script.cgi" checks the URI to decide what to do.
Before the spammers attack:
if ($ENV{REQUEST_URI} eq "/emailantwort.html") { send_mail(); }
Now:
if ($ENV{REQUEST_URI} eq "/someotherfile.html") {
send_mail_better(); }
if ($ENV{REQUEST_URI} eq "/emailantwort.html") { count_spmammer(); }
>
> In summary:
>
> Q1) How do I save the full query submitted to my CGI script.
>
> A) Look into methods provided for this purpose by CGI.pm and CGI::Minimal
Thank you, I will do so tonight.
> Q2) How do I prevent a spammer from using my script to send email to
> thousands of people?
>
> A) The safest way is to prevent a web site visitor from being able to
> enter any email address. Short of that, look at CGI::ContactForm to see
> how to make sure the submitted parameter only contains a single email
> address.
Thank you again. I will do my best.
> There seems to be nothing else that is remotely Perl related to discuss.
Okay? Didn't mean to annoy anybody.
Best regards
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
------------------------------
Date: Mon, 6 Feb 2006 15:12:25 +0000 (UTC)
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: SOAP::Lite example meets http server 500 error?
Message-Id: <Xns976267D3DCEAAasu1cornelledu@132.236.56.8>
"jck11" <jck11@msr.pchome.com.tw> wrote in
news:ds7n93$fkk$1@netnews.hinet.net:
> SOAP::Transport::HTTP::Client::send_receive: HTTP/1.0 500 Internal
Obviously, you have checked the server error logs to find out what the
actual error is, and to verify that this question actually has something to
do with Perl.
Care to tell us what you found out?
Sinan
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8925
***************************************
