Custom Directives turn off PHP
I wonder if anyone has ever seen this before - one of my AxKit users has found that custom directives are turning PHP off. For example: PHP simply doesn't even function with this configuration: VirtualHost 63.100.32.74:80 DocumentRoot /data/www/pdamd/docs AxDebugLevel 5 AxCacheModule Local::Apache::AxKit::Cache AxAddStyleMap application/x-xpathscript \ Apache::AxKit::Language::XPathScript AxAddStyleMap application/x-xsp Apache::AxKit::Language::XSP AxAddStyleMap text/xsl Apache::AxKit::Language::Sablot Files *.xml SetHandler perl-script PerlHandler AxKit PerlInitHandler Local::Vertical::Apache::ResetAds PerlInitHandler Local::Vertical::Apache::UserSession /Files /VirtualHost Whereas with this one it works fine: VirtualHost 63.100.32.74:80 DocumentRoot /data/www/pdamd/docs Files *.xml SetHandler perl-script PerlHandler AxKit PerlInitHandler Local::Vertical::Apache::ResetAds PerlInitHandler Local::Vertical::Apache::UserSession /Files /VirtualHost AxKit has a DIR_MERGE handler, and I wondered if it might be something to do with that, but I don't think so. AxKit's source code can be found at http://axkit.org/download/ - this is using the latest 0.99-pre release. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Module Function Name Issue
On Fri, 25 Aug 2000, Philip Molter wrote:
Do you have the two packages in the same file like you have presented
below? I guess they aren't since you have '1;' just before the declaration
of the second package. If they live in two different files obviously that
'use Object::SubObj' is mising, see the code below. Object doesn't know
about Object::SubObj if you don't tell it about it.
So how exactly your files are organized?
I have a module with some code like this:
package Object;
= use Object::SubObj;
sub new {
my $class = shift;
return bless {}, $class;
}
sub SubObj {
Object::SubObj-new();
}
1;
package Object::SubObj;
sub new {
my $class = shift;
return bless {}, $class;
}
I have a script with code like this:
$obj = Object-new();
$sub = Object-SubObj();
Now, I can spot the potential problem. Under regular perl, this
methodology works fine, has been for several years (that's how
long we've had this module). Under mod_perl, this setup works
fine. It has for several years. However, on a recent new system,
I decided that this module needed to be preloaded in a startup.pl-type
script, like so:
use Object;
Nothing fancy. When the script above is called in mod_perl now,
it goes into an endless loop. Apparently, the $obj-SubObj(); call
results in it calling itself continuously, as Object::SubObj is
mapped to the function, not the class. To fix it, I did:
sub SubObj {
'Object::SubObj'-new();
}
Why does this work under regular perl and under mod_perl, but under
mod_perl with this module preloaded, perl has a problem deciding
whether this is a function or a class? Is this a bug in mod_perl's
methodology or is it just another case of mod_perl catching bad
programming practice (no comments about the programming practice;
I only fix it)?
Is this in the Perl Guide? If so, I missed it. If not, would it
be appropriate to add it as an example? This was a challenge to
track down, especially with the way it affected the system (one
gets very scared running code he knows is going into an endless
loop in a location he can't determine).
* Philip Molter
* Data Foundry International
* http://www.datafoundry.net/
* [EMAIL PROTECTED]
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Patch to t/modules/request.t
On Fri, 25 Aug 2000, Rick Myers wrote:
On Aug 24, 2000 at 23:15:15 -0500, Ken Williams twiddled the keys to say:
[EMAIL PROTECTED] (Rick Myers) wrote:
On Aug 24, 2000 at 01:15:57 -0500, Ken Williams twiddled the keys to say:
The following patch eliminates a warning during 'make test' about 'Value
of HANDLE construct can be "0";'. No biggie, but it should be fixed.
--- t/modules/request.t 2000/05/12 03:43:24 1.8
+++ t/modules/request.t 2000/08/24 06:07:40
@@ -125,7 +125,7 @@
my $lines = 0;
local *FH;
open FH, $file or die "open $file $!";
-++$lines while (my $dummy = FH);
+++$lines while FH;
close FH;
my(@headers);
if ($Is_dougm) {
This reverses a previous patch that fixes a fatal 'Modification of a
read-only value attempted at modules/request.t line 128', which returns
with this patch.
See if this one finds us a happy median...
--- t/modules/request.t~ Thu Aug 24 18:24:39 2000
+++ t/modules/request.tThu Aug 24 18:41:22 2000
@@ -125,7 +125,7 @@
my $lines = 0;
local *FH;
open FH, $file or die "open $file $!";
-++$lines while (my $dummy = FH);
+++$lines while defined FH;
close FH;
my(@headers);
if ($Is_dougm) {
THAT's weird - what in the world is the read-only value that's being
modified?
It's $_.
Here's the relevant code from request.t to illustrate...
for ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($_);
}
sub upload_test {
++$lines while FH;
}
The real fix should be either:
for my $file ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($file);
}
sub upload_test {
++$lines while FH;
}
or
for ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($_);
}
sub upload_test {
local $_;
++$lines while FH;
}
The really one and the only correct one is of course:
for my $file ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($file);
}
sub upload_test {
local $_;
++$lines while FH;
}
You are trying to workaround the problem. It's always becomes very subtle
to find bug when you do:
for (1..5) { function($_) }
Because you never know whether the function itself is using $_ and
modifying it. In this situation you are lucky that the list you pass to
the for is readonly -- perl reports a problem. A much worth thing happen
when the variable that you pass to for() is a real array:
for (@array) { function($_) }
$_ is aliased to the real variables in @array -- it's not a copy!!! So if
function() alters $_, your array gets changed!!! This is a side effect
which can byte you very badly.
Therefore, if you are a good perl programmer and want your code to be
clean, when you write subroutines which work with $_, always start them
with:
local $_;
If you write for() and similar loops that alias $_ to the real variables
in the list, *always* do:
for my $val (@array) { foo($val) }
use $_ only if the loop doesn't call any function unless you are sure that
the function declares 'local $_';. The following is a perfect snippet of
code:
my $count = 0;
for (@values){
$count += $_;
}
The hint is that `while FH' will try to set $_ to the value of each
line read.
Rick Myers[EMAIL PROTECTED]
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Advice on migrating modperl from NT to Linux ?
On Sat, 26 Aug 2000, Rod Butcher wrote: I am looking to migrate a small modperl-based webhosting and ISP service from NT to some flavour of Linux. Are any particularly modperl-friendly or unfriendly or are they all much the same ? I'm fairly comfortable with Redhat, but I hear stories of packages being broken. Any feedback or pointers to discussions, articles etc would be much appreciated. The stories has nothing to do with any particular distro. Most distros come with apache compiled as DSO and that's where allmost all the woes are coming from. Most of the users of mod_perl use a static version of mod_perl, which you can build by yourself (see http://perl.apache.org/guide) or grab the rpm from http://perl.apache.org/distributions.html . _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Getting data from external URL
SB This one is much more efficient and requires even less coding:
SB use LWP::Simple;
SB $content = get("http://www.sn.no/")
Even better, thanks Stas.
Re: Patch to t/modules/request.t
On Aug 26, 2000 at 14:07:26 +0200, Stas Bekman twiddled the keys to say:
On Fri, 25 Aug 2000, Rick Myers wrote:
On Aug 24, 2000 at 23:15:15 -0500, Ken Williams twiddled the keys to say:
[EMAIL PROTECTED] (Rick Myers) wrote:
On Aug 24, 2000 at 01:15:57 -0500, Ken Williams twiddled the keys to say:
The following patch eliminates a warning during 'make test' about 'Value
of HANDLE construct can be "0";'. No biggie, but it should be fixed.
--- t/modules/request.t 2000/05/12 03:43:24 1.8
+++ t/modules/request.t 2000/08/24 06:07:40
@@ -125,7 +125,7 @@
my $lines = 0;
local *FH;
open FH, $file or die "open $file $!";
-++$lines while (my $dummy = FH);
+++$lines while FH;
close FH;
my(@headers);
if ($Is_dougm) {
This reverses a previous patch that fixes a fatal 'Modification of a
read-only value attempted at modules/request.t line 128', which returns
with this patch.
See if this one finds us a happy median...
--- t/modules/request.t~ Thu Aug 24 18:24:39 2000
+++ t/modules/request.t Thu Aug 24 18:41:22 2000
@@ -125,7 +125,7 @@
my $lines = 0;
local *FH;
open FH, $file or die "open $file $!";
-++$lines while (my $dummy = FH);
+++$lines while defined FH;
close FH;
my(@headers);
if ($Is_dougm) {
THAT's weird - what in the world is the read-only value that's being
modified?
It's $_.
Here's the relevant code from request.t to illustrate...
for ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($_);
}
sub upload_test {
++$lines while FH;
}
The real fix should be either:
for my $file ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($file);
}
sub upload_test {
++$lines while FH;
}
or
for ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($_);
}
sub upload_test {
local $_;
++$lines while FH;
}
I would lean towards the second one since upload_test() is called
similarly from three different places within request.t.
The reasoning behind suggesting `while defined FH' was that the
interaction with $_ appears to be unintentional, at least within the
scope of upload_test(). We're basically throwing away the content of the
file read anyway, so why not just eliminate the undesired setting of $_
altogether. Also, there's no need to localize $_ since we aren't
referencing it to do anything.
for ( qw(perlfunc.pod perlpod.pod perlxs.pod), @binary) {
upload_test($_);
}
sub upload_test {
my $podfile = shift || "func";
...
++$lines while defined FH;
}
FWIW, adding defined() was the perldiag-suggested fix for the problem
Ken was seeing. It also happens to fix the read-only error quite nicely
in this particular situation.
Rick Myers[EMAIL PROTECTED]
The Feynman Problem 1) Write down the problem.
Solving Algorithm 2) Think real hard.
3) Write down the answer.
Re: Module Function Name Issue
On Sat, Aug 26, 2000 at 01:56:18PM +0200, Stas Bekman wrote:
: On Fri, 25 Aug 2000, Philip Molter wrote:
:
: Do you have the two packages in the same file like you have presented
: below? I guess they aren't since you have '1;' just before the declaration
: of the second package. If they live in two different files obviously that
: 'use Object::SubObj' is mising, see the code below. Object doesn't know
: about Object::SubObj if you don't tell it about it.
:
: So how exactly your files are organized?
Actually, that '1;' was a mistake. Yes, they are both in the same
file, and no, that '1;' is not really there.
: I have a module with some code like this:
:
:package Object;
:
: = use Object::SubObj;
:
:sub new {
: my $class = shift;
: return bless {}, $class;
:}
:
:sub SubObj {
: Object::SubObj-new();
:}
:
:package Object::SubObj;
:sub new {
: my $class = shift;
: return bless {}, $class;
:}
:
: I have a script with code like this:
:
:$obj = Object-new();
:$sub = Object-SubObj();
:
: Now, I can spot the potential problem. Under regular perl, this
: methodology works fine, has been for several years (that's how
: long we've had this module). Under mod_perl, this setup works
: fine. It has for several years. However, on a recent new system,
: I decided that this module needed to be preloaded in a startup.pl-type
: script, like so:
:
:use Object;
:
: Nothing fancy. When the script above is called in mod_perl now,
: it goes into an endless loop. Apparently, the $obj-SubObj(); call
: results in it calling itself continuously, as Object::SubObj is
: mapped to the function, not the class. To fix it, I did:
:
:sub SubObj {
: 'Object::SubObj'-new();
:}
:
: Why does this work under regular perl and under mod_perl, but under
: mod_perl with this module preloaded, perl has a problem deciding
: whether this is a function or a class? Is this a bug in mod_perl's
: methodology or is it just another case of mod_perl catching bad
: programming practice (no comments about the programming practice;
: I only fix it)?
:
: Is this in the Perl Guide? If so, I missed it. If not, would it
: be appropriate to add it as an example? This was a challenge to
: track down, especially with the way it affected the system (one
: gets very scared running code he knows is going into an endless
: loop in a location he can't determine).
:
: * Philip Molter
: * Data Foundry International
: * http://www.datafoundry.net/
: * [EMAIL PROTECTED]
:
:
:
:
: _
: Stas Bekman JAm_pH -- Just Another mod_perl Hacker
: http://stason.org/ mod_perl Guide http://perl.apache.org/guide
: mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
: http://singlesheaven.com http://perlmonth.com perl.org apache.org
:
* Philip Molter
* Data Foundry International
* http://www.datafoundry.net/
* [EMAIL PROTECTED]
Re: Module Function Name Issue
On Sat, 26 Aug 2000, Philip Molter wrote:
On Sat, Aug 26, 2000 at 01:56:18PM +0200, Stas Bekman wrote:
: On Fri, 25 Aug 2000, Philip Molter wrote:
:
: Do you have the two packages in the same file like you have presented
: below? I guess they aren't since you have '1;' just before the declaration
: of the second package. If they live in two different files obviously that
: 'use Object::SubObj' is mising, see the code below. Object doesn't know
: about Object::SubObj if you don't tell it about it.
:
: So how exactly your files are organized?
Actually, that '1;' was a mistake. Yes, they are both in the same
file, and no, that '1;' is not really there.
The following is a known kludge, but it doesn't seem to apply in your
case (I thought you might use it in PerlHandler)
=head1 More package name related issues
If you have the following:
PerlHandler Apache::Work::Foo
PerlHandler Apache::Work::Foo::Bar
And you make a request that pulls in CApache/Work/Foo/Bar.pm first,
then the CApache::Work::Foo package gets defined, so mod_perl does
not try to pull in CApache/Work/Foo.pm
: I have a module with some code like this:
:
:package Object;
:
: = use Object::SubObj;
:
:sub new {
: my $class = shift;
: return bless {}, $class;
:}
:
:sub SubObj {
: Object::SubObj-new();
:}
:
:package Object::SubObj;
:sub new {
: my $class = shift;
: return bless {}, $class;
:}
:
: I have a script with code like this:
:
:$obj = Object-new();
:$sub = Object-SubObj();
How about:
$sub = Object::SubObj();
Your sub 'SubObj' isn't a method, so you should call it as a function and
not a method.
: Now, I can spot the potential problem. Under regular perl, this
: methodology works fine, has been for several years (that's how
: long we've had this module). Under mod_perl, this setup works
: fine. It has for several years. However, on a recent new system,
: I decided that this module needed to be preloaded in a startup.pl-type
: script, like so:
:
:use Object;
:
: Nothing fancy. When the script above is called in mod_perl now,
: it goes into an endless loop. Apparently, the $obj-SubObj(); call
: results in it calling itself continuously, as Object::SubObj is
: mapped to the function, not the class. To fix it, I did:
:
:sub SubObj {
: 'Object::SubObj'-new();
:}
:
: Why does this work under regular perl and under mod_perl, but under
: mod_perl with this module preloaded, perl has a problem deciding
: whether this is a function or a class? Is this a bug in mod_perl's
: methodology or is it just another case of mod_perl catching bad
: programming practice (no comments about the programming practice;
: I only fix it)?
:
: Is this in the Perl Guide? If so, I missed it. If not, would it
: be appropriate to add it as an example? This was a challenge to
: track down, especially with the way it affected the system (one
: gets very scared running code he knows is going into an endless
: loop in a location he can't determine).
:
: * Philip Molter
: * Data Foundry International
: * http://www.datafoundry.net/
: * [EMAIL PROTECTED]
:
:
:
:
: _
: Stas Bekman JAm_pH -- Just Another mod_perl Hacker
: http://stason.org/ mod_perl Guide http://perl.apache.org/guide
: mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
: http://singlesheaven.com http://perlmonth.com perl.org apache.org
:
* Philip Molter
* Data Foundry International
* http://www.datafoundry.net/
* [EMAIL PROTECTED]
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Advice on migrating modperl from NT to Linux ?
Also, another piece of advice for what it's worth. If your going to add SSL, build and test apache with mod-perl first, and then go back and add SSL. There may well be a work-around that I'm not aware of, but basically the problem is that mod-ssl is looking for an encryption key on startup, and mod-perl doesn't know anything about that. The result is that the server won't start and the mod-perl tests won't run. Better yet, don't put mod_perl and mod_ssl on the same server. The mod_perl guide has an excellent section on running seperate 'light' and 'heavy' servers. Basically you want to have a front end mod_ssl 'light' server for images and HTML, and 'heavy' server backend for mod_perl. All requests get tunneled through the 'light' server by using mod_proxy so as long as the traffic between your 'light' and 'heavy' servers is secure, you'll be fine. See http://perl.apache.org/guide/strategy.html#Do_Not_Put_mod_ssl_into_a_mod_pe
Re: Advice on migrating modperl from NT to Linux ?
On Sat, 26 Aug 2000, Rob Tanner wrote: RedHat is as good or bad as any of the distributions. Redhat is not my personal preference -- and note, I said preference. I don't back my opinion with lots of objective data because that's a subjective valuation. I've been using Caldera, but I've started playing with SuSE and I think I like it better. Also, I would stay away from distributions like Macmillan Linux for Windows or Phat Linux. The reason is that these are loopback distributions really designed for folks who need Linux and Windows but don't want to or don't have the facilities for dual-boot. The distribution is actually a file in a DOS partition. True. The advise is to go with mainstream distros (RH, Mandrake, SuSe, Debian, Other) otherwise you will be locked into yet another proprietary system with outdated sw. At least the mainstream distros get updated very soon. I prefer Mandrake since it's a little bit better than RH, and completely back compatible with RH (important when some sw pieces are released for RH only)... but this goes offtopic here, so I'd stop. The thing to be concerned about no matter what distribution you use is that the Perl, mod-perl, and Apache installed on the distribution is probably not at all current -- afterall, the CD was probably burned 6 months ago. Download current source and build your own. Also, don't install mod-perl as a DSO. It'll work kinda' sometimes maybe. It's considered experimental and that means NOT production. Build mod-perl static. True. Also, another piece of advice for what it's worth. If your going to add SSL, build and test apache with mod-perl first, and then go back and add SSL. There may well be a work-around that I'm not aware of, but basically the problem is that mod-ssl is looking for an encryption key on startup, and mod-perl doesn't know anything about that. The result is that the server won't start and the mod-perl tests won't run. Heh, obviously you have to supply the password on the server startup, unless you use one of the workarounds described in the ssl docs (secured utility that feeds the passwd is the best IMHO). Apparently this is not a reason to first build mod_perl without ssl. The real reason is a level of complexity and a number of things that can go wrong -- this is true for any complex Apache modules, like mod_perl, mod_ssl and others. For those exprerienced, all these are the piece of cake and obviously they install all at once. If you are new to mod_perl exercise first the installation of mod_perl over plain Apache, get your feet wet. Then add other things on top when you are confident about the things you do. And of course like many have mentioned already, it's better to install mod_ssl and alike in the front end server. See an extensive discussion in the mail archives and somewhere in the guide. -- Rob --On 08/26/00 23:22:03 +1000 Rod Butcher [EMAIL PROTECTED] wrote: I am looking to migrate a small modperl-based webhosting and ISP service from NT to some flavour of Linux. Are any particularly modperl-friendly or unfriendly or are they all much the same ? I'm fairly comfortable with Redhat, but I hear stories of packages being broken. Any feedback or pointers to discussions, articles etc would be much appreciated. Thanks Rod _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED] _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Module Function Name Issue
On Sat, 26 Aug 2000, Philip Molter wrote:
On Sat, Aug 26, 2000 at 05:22:27PM +0200, Stas Bekman wrote:
: The following is a known kludge, but it doesn't seem to apply in your
: case (I thought you might use it in PerlHandler)
:
: =head1 More package name related issues
:
: If you have the following:
:
: PerlHandler Apache::Work::Foo
: PerlHandler Apache::Work::Foo::Bar
:
: And you make a request that pulls in CApache/Work/Foo/Bar.pm first,
: then the CApache::Work::Foo package gets defined, so mod_perl does
: not try to pull in CApache/Work/Foo.pm
Yes, I read that. I don't know if the issue is one in the same.
Because they are in the same file, Object.pm is definitely being
loaded first. However, what happens differently when a module is
loaded at initial startup versus when the same module is loaded
when a script runs?
Do you see the same behaviour if you split the two packages into two
different files?
: : I have a module with some code like this:
: :
: :package Object;
: :
: : = use Object::SubObj;
: :
: :sub new {
: : my $class = shift;
: : return bless {}, $class;
: :}
: :
: :sub SubObj {
: : Object::SubObj-new();
: :}
: :
: :package Object::SubObj;
: :sub new {
: : my $class = shift;
: : return bless {}, $class;
: :}
: :
: : I have a script with code like this:
: :
: :$obj = Object-new();
: :$sub = Object-SubObj();
:
: How about:
:
: $sub = Object::SubObj();
:
: Your sub 'SubObj' isn't a method, so you should call it as a function and
: not a method.
Well, except, in the effort to simplify all this, the $obj-SubObj()
method doesn't just pass in nothing. It passes in various bits of
information contained in the Object-class object. The sub SubObj
is more like:
sub SubObj {
my ( $this ) = @_;
Object::SubObj-new( $this-{'var1'}, $this-{'var2'} );
}
So it's actually tied pretty much to the POO interface. I mean,
it's basically not /that/ big a deal, because by writing it:
sub SubObj {
my ( $this ) = @_;
'Object::SubObj'-new( $this-{'var1'}, $this-{'var2'} );
}
the whole problem is averted. I'm really just wondering what
happens differently when the module is loaded from a startup.pl
script via PerlRequire (the PerlHandler is Apache::Registry) versus
when it's loaded as a result of a script call, because those
differences may cause other problems in the future.
I'd try to run it under debugger and see where the problem occurs. If you
can send a *short* and *simple* example that one can reproduce the problem
with someone will test it.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Apache::ASP #include file
Philip Mak wrote: Recently, I reinstalled mod_perl and Apache::ASP on my system in order to fix a problem I was having with ASP not using the new version of perl on my system. However, I'm having problem with some old code. I used to do this: In httpd.conf: PerlSetVar IncludesDir /home/goamembers/www In an ASP script: !--#include file="/index.inc"-- Notice the "/" in "/index.inc". This would force it to get index.inc from /home/goamembers/www, instead of the current directory. This makes it kind of like !--#include virtual-- does with respect to filenames that start with "/" (but include virtual cannot be used to inline asp code). That functionality was never intended to be supported, and am surprised it ever worked! How painful would it be for you to change your includes to be like !--#include file="index.inc"-- -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Getting data from external URL
Hello,
Thanks everyone for such a simple solutions.
I think I will use followig method as it seems much simpler.
Thanks
Vijay
- Original Message -
From: "Rodney Broom" [EMAIL PROTECTED]
To: "Stas Bekman" [EMAIL PROTECTED]
Cc: "Vijay" [EMAIL PROTECTED]; "mod_perl Maillinglist" [EMAIL PROTECTED]
Sent: Saturday, August 26, 2000 10:24 AM
Subject: Re: Getting data from external URL
SB This one is much more efficient and requires even less coding:
SB use LWP::Simple;
SB $content = get("http://www.sn.no/")
Even better, thanks Stas.
Re: Cookies
Jeff Smelser wrote:
How do you set expires in ASP cookies?
I tried, and various other ways too. Even nodeworks.com wouldn't work for
me. Thanks.
$expires=HTTP::Date::time2str(time()+86400);
$Response-{Cookies}{'username','Expires', '$expires'} =
$Request-Form('username');
$Response-{Cookies}{'password'} = $Request-Form('password');
Try:
$Response-{Cookies}{username} = {
Expires = 86400,
Value = $Request-{Form}{username}
};
or
$Response-Cookies('username', 'Expires', 86400);
$Response-Cookies('username', 'Value', $Request-Form('username'));
See the $Response-Cookies collection in the OBJECTS section
of the README or the website http://www.apache-asp.org
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Advice on migrating modperl from NT to Linux ?
--On 08/26/00 18:51:31 +0200 Stas Bekman [EMAIL PROTECTED] wrote: Heh, obviously you have to supply the password on the server startup, unless you use one of the workarounds described in the ssl docs (secured utility that feeds the passwd is the best IMHO). Naw, something else is going on and I just haven't had the time ( or inclination -- all the pieces are working together without a hitch) to really investigate it. I, in fact, run my SSL servers as you suggest since I don't like to be around to have to provise a password. The crux of the problem is that mod-perl, in it's test phase, is quit unaware -- or seems to be -- of any configuration outside of what it sets up for itself when running 'make test'. Moreover, if you're building for the first time, you won't have anything in place yet. Hmm, I don't remember one around to test and was long time ago when I've installed the last one, but I think there were no problems at that stage. Am I wrong? And of course like many have mentioned already, it's better to install mod_ssl and alike in the front end server. See an extensive discussion in the mail archives and somewhere in the guide. The problem with light and heavy servers is that what is technically the best option and corporate culture often clash with corporate culture winning more often than not. To use mod_proxy on a "light" SSL server acting as a mirror for the real beast requires certain constraints in how links are specified (this we all know). I work in higher education, a 4 year college to be exact. We have a webmaster who is really only in charge of content. I'm the technical systems guy. But even though content is the webmaster's job, he hasn't got complete control. Many a professor is in charge of various academic departmental web pages. You talk about relative links and he has no idea what you're talking about, and doesn't want to know. Nor is he willing to change the way he does things, he hasn't got time to learn a new tool, etc, etc, etc. And the thing with tenured faculty is they win -- even in cases where they're being totally uncooperative (I decided to be polite here) for no reason other than they don't feel like being cooperative. There is no need for a relative links. You should use mod_rewrite and/or mod_proxy to ProxyPass the requests fron the light server to another see: http://perl.apache.org/guide/scenario.html#Concepts_and_Configuration_Direc So once you have things installed it's absolutely transparent for your content writers. We use SSL on our main external server because enrollment will soon be taking on-line applications and payment for distance learning and our bookstore is doing e-commerce, and everybody wants they're URL to be the main campus server. So, what you say is absolutely true is we lived in an ideal world where the technically best option defined the course of action because it was technically best. But we live in a world where non-technical issues cloud the decision process, and for non-technical reasons we are sometimes stuck with a technically poor solution. I'm almost sure that you can find a solution that will be nice to the content provider and technicaly sophisticated. There are lots of examples of different techniques in the guide and I'm sure that there are many more that aren't there. Of course I might be wrong and in your particular situation none will apply, but it worth investigation. BTW Stas, I haven't downloaded the current version of the guide, I'm using 1.24 so my comments might be dated. But, if folks in the US simply follow your instructions they will be illegal even after Sept 21. Using the rsaref libraries is an absolute requirement. Take a look at the mod_ssl install instructions and you might want to incorporate them in the guide at the appropriate spot. Just a suggestion. Weird, it's a first time I hear about that. The Guide explains the details of installation of the apache-ssl, mod_ssl and few others, which I don't think have any US regulation problems. I might be wrong of course, since I'm not in US... But if there is a real problem with this, I'll definitely add a note in the appropriate place. I really don't want someone to have troubles with the material in the Guide. I'm really surprised nobody have ever rised this issue before. I know for sure that *some* people on the list and among Guide readers are American :) So just tell me what to fix and where, and I'll do it. P.S. I think the ssl notes in the guide are at least one year old. How many of you had a legal trouble with these notes? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com
Re: Apache::ASP #include file
On Aug 26, [EMAIL PROTECTED] contorted a few electrons to say... Philip Philip Mak wrote: Philip Philip Recently, I reinstalled mod_perl and Apache::ASP on my system in order to Philip fix a problem I was having with ASP not using the new version of perl on Philip my system. However, I'm having problem with some old code. Philip Philip I used to do this: Philip Philip In httpd.conf: PerlSetVar IncludesDir /home/goamembers/www Philip In an ASP script: !--#include file="/index.inc"-- Philip Philip Notice the "/" in "/index.inc". This would force it to get index.inc from Philip /home/goamembers/www, instead of the current directory. This makes it kind Philip of like !--#include virtual-- does with respect to filenames that start Philip with "/" (but include virtual cannot be used to inline asp code). Philip Philip Philip That functionality was never intended to be supported, and Philip am surprised it ever worked! How painful would it be for Philip you to change your includes to be like !--#include file="index.inc"-- while we are on this topic, is there any chance Apache::ASP could look at IncludesDir when executing global.asa? it doesn't seem to AFAICT. jr -- Joel W. Reed412-257-3881 Verbosity leads to unclear, inarticulate things. PGP signature
Re: Advice on migrating modperl from NT to Linux ?
Well, the legal troubles should be outlined in the mod_ssl docs. I think it just has to do with using the rsa_ref libraries because of a patent held in the USA. But I haven't looked at it lately. In theory you're supposed to get a license to use it. When you buy StrongHold or another commercial version of SSL apache, that company has already paid the licensing to use those encryption algorithms. "Down the street" from us in Singapore is a company called 3UI that makes an open source secure WAP Gateway and they have the same issues. They distribute the code to compile it, but they can't legally distribute the rsa_ref stuff with their software so that the WAP version of SSL will compile into the server. In passing, a few weeks ago one of them mentioned me though that even when the patent expires, there are still other patents that are held which will prevent full distribution of source unfortunately. My caveat on saying this is that I may not be remembering the exact words -- and in legal cases, words can make all the difference. So you should check for yoursel what mod_ssl and the ssleay docs say. From the website of 3UI (regarding the compiling of WTLS -- WAP SSL) "Note: The open source version of the WTLS does not include the RC5 block cipher and the RSA key exchange algorithms as they have been patented by RSA. If you need any of these, you will have to buy the commercial version of this software from us. " By the way, as a plug, I would have to say that if anyone is doing secure transactions with WAP, you might consider supporting these guys. They've put a lot of $ and hours into making their WAP gateway (originally based off of Kannel but rewritten for more efficient threading and scalability). So to make it open source after spending so much real money on development is really forward thinking for a VC funded company. It's also well-abstracted so it compiles ok under both Linux *and* Windows NT (gasp!). Later, Gunther At 02:49 AM 8/27/00 +0200, Stas Bekman wrote: --On 08/26/00 18:51:31 +0200 Stas Bekman [EMAIL PROTECTED] wrote: [...snipped...] BTW Stas, I haven't downloaded the current version of the guide, I'm using 1.24 so my comments might be dated. But, if folks in the US simply follow your instructions they will be illegal even after Sept 21. Using the rsaref libraries is an absolute requirement. Take a look at the mod_ssl install instructions and you might want to incorporate them in the guide at the appropriate spot. Just a suggestion. Weird, it's a first time I hear about that. The Guide explains the details of installation of the apache-ssl, mod_ssl and few others, which I don't think have any US regulation problems. I might be wrong of course, since I'm not in US... But if there is a real problem with this, I'll definitely add a note in the appropriate place. I really don't want someone to have troubles with the material in the Guide. I'm really surprised nobody have ever rised this issue before. I know for sure that *some* people on the list and among Guide readers are American :) So just tell me what to fix and where, and I'll do it. P.S. I think the ssl notes in the guide are at least one year old. How many of you had a legal trouble with these notes? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Advice on migrating modperl from NT to Linux ?
At 11:31 AM 8/26/00 -0700, Rob Tanner wrote: --On 08/26/00 18:51:31 +0200 Stas Bekman [EMAIL PROTECTED] wrote: Heh, obviously you have to supply the password on the server startup, unless you use one of the workarounds described in the ssl docs (secured utility that feeds the passwd is the best IMHO). [snipped...] Actually I think that the best is a hardware SSL solution that also stores the certificate inside of itself. It's really nice because the hardware does the SSL for you so the web server never needs the cert. And once you've set up the hardware, you are supposed to be able to simply flip a jumper and then the cert is no longer readable or writable since it's stored in the SSL card itself. I believe that several of the flavors of SSL accelerator provide this capability. Plus they lower the calculation latency of establishing the SSL connection because they accelerate the public/private key exchange part of the SSL protocol. Usually this isn't so big a deal for most sites though. I may be wrong though.
Re: Apache::ASP #include file
Recently, I reinstalled mod_perl and Apache::ASP on my system in order to fix a problem I was having with ASP not using the new version of perl on my system. However, I'm having problem with some old code. That functionality was never intended to be supported, and am surprised it ever worked! How painful would it be for you to change your includes to be like !--#include file="index.inc"-- apache_ssl and mod_perl co-exist nicely together, try that instead. I've a couple of these in production environments that work very well. Michael
Re: Apache::ASP #include file
On Sat, 26 Aug 2000, Michael Robinton wrote: apache_ssl and mod_perl co-exist nicely together, try that instead. I've a couple of these in production environments that work very well. I don't understand... what does SSL have to do with this? -Philip Mak ([EMAIL PROTECTED]) Recently, I reinstalled mod_perl and Apache::ASP on my system in order to fix a problem I was having with ASP not using the new version of perl on my system. However, I'm having problem with some old code. That functionality was never intended to be supported, and am surprised it ever worked! How painful would it be for you to change your includes to be like !--#include file="index.inc"--
Re: Apache::ASP #include file
On Sat, 26 Aug 2000, Michael Robinton wrote: apache_ssl and mod_perl co-exist nicely together, try that instead. I've a couple of these in production environments that work very well. I don't understand... what does SSL have to do with this? -Philip Mak ([EMAIL PROTECTED]) Oops, responded to the wrong thread ... gotta backup and take another look
RE: Getting data from external URL
Hello Vijay,
You can make simple HTTP GET or POST requests
using the LWP and HTTP modules. I recommend
that you read the ActivePerl help files.
I have attached the one you really need but
it probably won't make sense unless you read
up on LWP.
# A small sample follows:
use LWP::UserAgent;
# use HTTP::Request::Common qw(POST);
$ua = new LWP::UserAgent;
$ua-agent("Netscape 3.0");
$page_url =
'http://www.1freestuff.com/cgi-bin/topsites/topsites.cgi?puzzler';
$response = get($page_url); # Do a GET.
# print $response-as_string;
# Get the NEW form number:
$content = $response-content;
$content =~ m/(value=")(\d.*)(")/ig;
$number = $2;
print "The magic number is: " . $number;
sub get {
my $page_url = $_[0];
my $request = new HTTP::Request(GET, "$page_url");
my $response = $ua-request($request);
return $response;
};
-Original Message-
From: Vijay [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 25, 2000 11:15 PM
To: [EMAIL PROTECTED]; mod_perl Maillinglist
Subject: Getting data from external URL
Hello,
I want to get data from an external url in my perl program (either thru
Embperl Execute or directly from perl). What I need is like this.
There is a URL which gives some information in text format. I want to get
that into a variable or file using perl and using my own html templates, I
want to show that data.
If anyone has done something like this, please let me know.
Thanks
Vijay
Title: HTTP::Request::Common - Construct common HTTP::Request objects
HTTP::Request::Common - Construct common
HTTP::Request objects
NAME
SUPPORTED
PLATFORMS
SYNOPSIS
DESCRIPTION
SEE
ALSO
COPYRIGHT
NAME
HTTP::Request::Common - Construct common HTTP::Request objects
SUPPORTED PLATFORMS
Linux
Solaris
Windows
SYNOPSIS use HTTP::Request::Common;
$ua = LWP::UserAgent-new;
$ua-request(GET 'http://www.sn.no/');
$ua-request(POST 'http://somewhere/foo', [foo = bar, bar = foo]);
DESCRIPTION
This module provide functions that return newly created HTTP::Request
objects. These functions are usually more convenient to use than the standard
HTTP::Request constructor for these common requests. The following functions are
provided.
GET
$url, Header = Value,...
The GET() function returns a HTTP::Request object initialized
with the GET method and the specified URL. Without additional arguments it is
exactly equivalent to the following call HTTP::Request-new(GET = $url)
but is less cluttered. It also reads better when used together with the
LWP::UserAgent-request() method: my $ua = new LWP::UserAgent;
my $res = $ua-request(GET 'http://www.sn.no/')
if ($res-is_success) { ...
You can also initialize header values in the request by specifying some
key/value pairs as optional arguments. For instance: $ua-request(GET 'http://www.sn.no/',
If_Match = 'foo',
From = '[EMAIL PROTECTED]',
);
A header key called 'Content' is special and when seen the value will
initialize the content part of the request instead of setting a header.
HEAD $url,
[Header = Value,...]
Like GET() but the method in the request is HEAD.
PUT $url, [Header
= Value,...]
Like GET() but the method in the request is PUT.
POST $url,
[$form_ref], [Header = Value,...]
This works mostly like GET() with POST as the method, but
this function also takes a second optional array or hash reference parameter
($form_ref). This argument can be used to pass key/value pairs for the form
content. By default we will initialize a request using the
application/x-www-form-urlencoded content type. This means that
you can emulate a HTML form POSTing like this: POST 'http://www.perl.org/survey.cgi',
[ name = 'Gisle Aas',
email = '[EMAIL PROTECTED]',
gender = 'M',
born = '1964',
perc = '3%',
];
This will create a HTTP::Request object that looks like this: POST http://www.perl.org/survey.cgi
Content-Length: 66
Content-Type: application/x-www-form-urlencoded name=Gisle%20Aasemail=gisle%40aas.nogender=Mborn=1964perc=3%25
The POST method also supports the multipart/form-data content
used for Form-based File Upload as specified in RFC 1867. You trigger
this content format by specifying a content type of 'form-data'
as one of the request headers. If one of the values in the $form_ref is an
array reference, then it is treated as a file part specification with the
following interpretation: [ $file, $filename, Header = Value... ]
The first value in the array ($file) is the name of a file to open. This
file will be read and its content placed in the request. The routine will
croak if the file can't be opened. Use an undef
as $file value if you want to specify the content directly. The $filename is
the filename to report in the request. If this value is undefined, then
Re: Getting data from external URL
OK, lots of banter... Hey V, if you are on a *NIX system, then this is a fast way: open U, "lynx -source www.some.url.dom |"; $data = join '', U; There, you're finished. Admittedly, this isn't terribly efficiant, but it works just fine and has short devel time. Rodney Broom
Re: Getting data from external URL
On Sat, 26 Aug 2000, Rodney Broom wrote:
OK, lots of banter...
Hey V, if you are on a *NIX system, then this is a fast way:
open U, "lynx -source www.some.url.dom |";
$data = join '', U;
There, you're finished. Admittedly, this isn't terribly efficiant, but it works
just fine and has short devel time.
This one is much more efficient and requires even less coding:
use LWP::Simple;
$content = get("http://www.sn.no/")
And it doesn't require you to be on any particular OS, as far as I know.
see perldoc LWP::Simple and as advised by many others LWP::UserAgent for
more advanced uses.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Getting data from external URL
Hello, I want to get data from an external url in my perl program (either thru Embperl Execute or directly from perl). What I need is like this. There is a URL which gives some information in text format. I want to get that into a variable or file using perl and using my own html templates, I want to show that data. If anyone has done something like this, please let me know. HTML::Embperl::ProxyInput maybe (ab)used to fetch the data from the remote host Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
