Apache::ASP and server-side includes
Is it possible to configure Apache so that .asp files also support server-side includes?. I can configure Apache to successfully make .shtml files support server-side includes but the asp files have a .asp extension and if I change the handler for that, I'll end up disabling Apache::ASP. How do I get server-side includes to work as well, for files with an .asp extension?
Re: ANNOUNCE: HTML::Embperl 1.2.0
On Wed, Nov 17, 1999 at 08:23:07AM +0100, Gerald Richter wrote: The URL ftp://ftp.dev.ecos.de/pub/perl/embperl/HTML-Embperl-1.2.0.tar.gz has entered CPAN as [...] Are Gerald's and Jeffrey's Apache::Session back in sync now? Ajit
multipart POST problems
This is a resend - for some reason I'm having problems sending to the list
from my main email account. Doh!
-jse
I've been attempting to write a perl module that handles POSTs of type
multipart/form-data, and have been having a rough time.
I'm using Apache::Request to process the request. I have dumped the
content-type of the incoming request, and verified that it's
"multipart/form-data". I can use param() to get the parameters, but I can't
seem to use upload() to access the blocks directly.
I've included the code from my test handler below. Basically it attempts to
access a large parameter MIME block two ways - using param() and using
upload(). The param() version works fine, but the upload() version can't
find the block.
Any clues? The only thing that I can think of is that for this test case,
the MIME type of the "message" block is text/plain (it's in a TEXTAREA
field, for testing purposes). Is it possible that Apache::Request will not
allow me to process "normal" form fields with upload()?
-jse
sub handler
{
my $r = shift;
my $apr = Apache::Request-new($r);
my $block;
my $buffer;
$r-content_type('text/html');
$r-send_http_header();
$buffer = $apr-param('message');
$r-print("bMessage:/bbrpre$buffer/prebr");
$block = $apr-upload('message');
if ($block)
{
$r-print("Found message");
}
else
{
$r-print("No message");
}
return OK;
}
ANNOUNCE: CGI::WeT 0.71
The uploaded file CGI-WeT-0.71.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JS/JSMITH/CGI-WeT-0.71.tar.gz size: 40841 bytes md5: 78528519a7a96511b96064d9a4d750ce CGI::WeT is a package to help build a website with the ability to offer different views for the same content. CGI::WeT prefers Apache with mod_perl but can be made to work without mod_perl with a little more effort. Version 0.71 provides almost complete emulation of CGI.pm. Any differences from normal operation after converting a script from CGI to CGI::WeT should be considered bugs in CGI::WeT (unless they aren't). Please report them to the cgi-wet mailing list. -- James Smith [EMAIL PROTECTED]
Re: Stonehenge::Throttle, round 2 - CPU used by an IP
On Tue, 16 Nov 1999, Matt Sergeant wrote:
For the unique IP in _most_ firewall cases, take the last comma separated
value of the X-Forwarded-For header: $r-headers_in-get('x-forwarded-for');
except for all the clients at 192.168.1.100 (etc).
So you would have to get into "real ip / forwarded for" pairs, and the
harmful stupid people would at some point figure that out and put random
"forwarded for" thingies into their clients. Don't use anything but the
real ip for anything related to access policies based on ip addresses.
- ask
--
ask bjoern hansen - http://www.netcetera.dk/~ask/
more than 60M impressions per day, http://valueclick.com
Re: ANNOUNCE: HTML::Embperl 1.2.0
On Wed, Nov 17, 1999 at 08:23:07AM +0100, Gerald Richter wrote: The URL ftp://ftp.dev.ecos.de/pub/perl/embperl/HTML-Embperl-1.2.0.tar.gz has entered CPAN as [...] Are Gerald's and Jeffrey's Apache::Session back in sync now? I have moved the interface between Apache::Session and Embperl to the Embperl distribution, (named now HTML::Embperl::Session instead of Apache::Session::Embperl), so Embperl 1.2.0 will work with _any_ Apache::Session 1.xx version :-), so you do _not_ need my Apache::Session versions (1.01,02,04) anymore. Gerald
RE: perl variable in configs for few virtual servers
Andrei,
I do not see this behavior if I use PerlSetVar directly inside a VirtualHost
section instead of via a ResourceConfig. I do see it if I move the directive
to the main server, so I suppose it's a scope issue with ResourceConfig.
It's Apache 1.3.9, mod_perl 1.21 on Linux.
The only change I have is patch for correcting PATH enviroment
corruption provided by Doug.
Andrei
On Tue, Nov 16, 1999 at 05:29:46PM +0100, Eric Cholet wrote:
Which version of mod_perl are you using, 1.21 or the CVS version perhaps?
Hi!
I've encountered very interesting problem. When I set some variable
using PerlSetVar in configuration files for different virtual servers
they seem to be available to ALL of those virtual servers.
Here's details to clarify.
In httpd.conf I have
VirtualHost myhost1.domain.com
ServerName myhost1.domain.com
DocumentRoot /httpd/docs
ErrorLog logs/httpd-errors
CustomLog logs/httpd-log common
AccessConfig conf/access.conf
ResourceConfig conf/srm.conf
/VirtualHost
VirtualHost myhost2.domain.com
ServerName myhost2.domain.com
DocumentRoot /httpd/docs
ErrorLog logs/httpd2-errors
CustomLog logs/httpd2-log common
AccessConfig conf/access2.conf
ResourceConfig conf/srm2.conf
/VirtualHost
Now in srm.conf I set
PerlSetVar MyVariable MyValue
PerlAuthenHandlerApache::Myhandler
And in srm2.conf I have
PerlSetVar MyVariable2 MyValue2
PerlAuthenHandlerApache::Myhandler
In Myhandler::handler I do
$myvar1 = $r-dir_config('MyVariable');
$myvar2 = $r-dir_config('MyVariable2);
if($myvar1){
## do stuff for first virtual server
}else{
## do stuff for the second one
}
But $myvar1 appears to be ALWAYS set. Which leads me to belief that
mod_perl "shares" variables between virtual servers if those variables
are not explicitly set in configuration for that server.
Is this supposed to be this way? Or am I missing something?
Andrei
--
Eric
RE: multipart POST problems
My understanding is that upload() is only for input type="file" only and
that param() handles all of the other form elements. That's how I've
implemented it here and all works as expected.
BTW, I don't do any checking to see how the form was submitted. I use
Apache::Request for all of my form submission methods and everything works
fine, no matter how the information was submitted.
--
From: John S. Evans[SMTP:[EMAIL PROTECTED]]
Sent: Thursday, November 18, 1999 5:54 PM
To: modperl
Cc: [EMAIL PROTECTED]
Subject: multipart POST problems
I've been attempting to write a perl module that handles POSTs of type
multipart/form-data, and have been having a rough time.
I'm using Apache::Request to process the request. I have dumped the
content-type of the incoming request, and verified that it's
"multipart/form-data". I can use param() to get the parameters, but I
can't
seem to use upload() to access the blocks directly.
I've included the code from my test handler below. Basically it attempts
to
access a large parameter MIME block two ways - using param() and using
upload(). The param() version works fine, but the upload() version can't
find the block.
Any clues? The only thing that I can think of is that for this test case,
the MIME type of the "message" block is text/plain (it's in a TEXTAREA
field, for testing purposes). Is it possible that Apache::Request will
not
allow me to process "normal" form fields with upload()?
-jse
sub handler
{
my $r = shift;
my $apr = Apache::Request-new($r);
my $block;
my $buffer;
$r-content_type('text/html');
$r-send_http_header();
$buffer = $apr-param('message');
$r-print("bMessage:/bbrpre$buffer/prebr");
$block = $apr-upload('message');
if ($block)
{
$r-print("Found message");
}
else
{
$r-print("No message");
}
return OK;
}
Re: Apache::ASP and server-side includes
Lookup $Response-Include() in the docs. It is used for exactly this purpose. -Mike Andrew Mayo wrote: Is it possible to configure Apache so that .asp files also support server-side includes?. I can configure Apache to successfully make .shtml files support server-side includes but the asp files have a .asp extension and if I change the handler for that, I'll end up disabling Apache::ASP. How do I get server-side includes to work as well, for files with an .asp extension? -- ISIS 2000, Inc. Your e-Partner. Not e-Vendor e-Business, Systems Integration and Enterprise Management solutions http://www.isis2000.com
Re: perl variable in configs for few virtual servers
Ok. I think I've figured that out
Reading documentation on Apache ResourceConfig directive. It states
--
Syntax: ResourceConfig filename
Default: ResourceConfig conf/srm.conf
Context: server config, virtual host
Status: core
The server will read this file for more directives after reading the
httpd.conf file. Filename is relative to the ServerRoot. This feature
can be disabled using:
ResourceConfig /dev/null
--
Which explains everything. I have 2 configs srm.conf and srm1.conf.
The first one is read BEFORE defining virtual servers that is why
variables from it are available in all virtual servers.
As usually I should have RTFM before complaining :)
Andrei
On Fri, Nov 19, 1999 at 10:09:33AM -0500, Andrei A. Voropaev wrote:
Let me try that.
Andrei
On Fri, Nov 19, 1999 at 03:43:40PM +0100, Eric Cholet wrote:
But do you see the behaviour I see, that is, the problem is related to
the fact that you're using ResourceConfig? If you do this:
VirtualHost host1
PerlSetVar var1 value1
/VirtualHost
VirtualHost host2
PerlSetVar var2 value2
/VirtualHost
Now when you call a script in host2 do you see var1 as being set?
Interesting. I can reproduce this problem on my machine easily. And
it's pretty painful too because customers couldn't access my second
virtual server for exactly that reason. As a quick fix I had to set
the same variable to have different values. This works perfectly.
Maybe it has something to do with the way I've set up my virtual
hosts?
I've checked few times already. I don't source srm.conf anywhere
outside of VirtualHost/VirtualHost, so the problem is not there
definetely.
Anyway, I'll read Apache documentation on setting up Virtual
Hosts. And do more testing. Basically this has come up only because I
was too lazy to change couple lines in my module to expect different
values from the same variable.
Andrei
On Fri, Nov 19, 1999 at 12:40:24PM +0100, Eric Cholet wrote:
Andrei,
I do not see this behavior if I use PerlSetVar directly inside a VirtualHost
section instead of via a ResourceConfig. I do see it if I move the directive
to the main server, so I suppose it's a scope issue with ResourceConfig.
It's Apache 1.3.9, mod_perl 1.21 on Linux.
The only change I have is patch for correcting PATH enviroment
corruption provided by Doug.
Andrei
On Tue, Nov 16, 1999 at 05:29:46PM +0100, Eric Cholet wrote:
Which version of mod_perl are you using, 1.21 or the CVS version perhaps?
Hi!
I've encountered very interesting problem. When I set some variable
using PerlSetVar in configuration files for different virtual servers
they seem to be available to ALL of those virtual servers.
Here's details to clarify.
In httpd.conf I have
VirtualHost myhost1.domain.com
ServerName myhost1.domain.com
DocumentRoot /httpd/docs
ErrorLog logs/httpd-errors
CustomLog logs/httpd-log common
AccessConfig conf/access.conf
ResourceConfig conf/srm.conf
/VirtualHost
VirtualHost myhost2.domain.com
ServerName myhost2.domain.com
DocumentRoot /httpd/docs
ErrorLog logs/httpd2-errors
CustomLog logs/httpd2-log common
AccessConfig conf/access2.conf
ResourceConfig conf/srm2.conf
/VirtualHost
Now in srm.conf I set
PerlSetVar MyVariable MyValue
PerlAuthenHandlerApache::Myhandler
And in srm2.conf I have
PerlSetVar MyVariable2 MyValue2
PerlAuthenHandlerApache::Myhandler
In Myhandler::handler I do
$myvar1 = $r-dir_config('MyVariable');
$myvar2 = $r-dir_config('MyVariable2);
if($myvar1){
## do stuff for first virtual server
}else{
## do stuff for the second one
}
But $myvar1 appears to be ALWAYS set. Which leads me to belief that
mod_perl "shares" variables between virtual servers if those variables
are not explicitly set in configuration for that server.
Is this supposed to be this way? Or am I missing something?
Andrei
--
Eric
--
--
--
A few pointers, please.
From: Dave Pfaltzgraff@PATAPSCO on 11/19/99 01:45 PM I'm fairly new at this and need a few pointers to possible resources. I've used Apache::AuthenDBI and thus require the user to enter a user name and password as expected. It all works. However, my customer has asked for either a timeout, a [Logout] button, or both so that the browser basically 'forgets' the user id. This would then remove the requirement for the user to close down the browser when they leave their system. Where can I look for assistence on this problem? My assumption is that it would be a 'browser' thing so I wouldn't expect a direct answer from this group. Thanks, Dave
Re: Bug in libapreq makes form elements stick to an apache child
Cliff Rayman wrote: `perldoc -f defined` yields a couple of sentences: You may also use Cdefined() to check whether a subroutine exists, by saying Cdefined func without parentheses. On the other hand, use of Cdefined() upon aggregates (hashes and arrays) is not guaranteed to produce intuitive results, and should probably be avoided. I hate it when that happens. why not use: if(@foo_in) instead of: if (defined @foo_in) Yeah. I guess the reason I do the latter is b/c I want the code to reflect what I am actually trying to test. I don't really want to test the trueness of @foo, I want to test for it's existence. But in perl the operation is overloaded. Feh. I think I will test for defined $foo_in[0] instead. -- Jeffrey W. Baker * [EMAIL PROTECTED] Critical Path, Inc. * we handle the world's email * www.cp.net 415.808.8807
Re: Image::Magick and mod_perl
On Mon, 15 Nov 1999, Todd Finney wrote: process for the duration of the transaction? If each transaction lasts a couple of seconds, it this a Bad Thing? Is there a more efficient way to handle this? Unless you truly need to resize the image on the fly as part of the transaction with the client I think this is probably a waste of a good mod perl server. Someone previously mentioned sticking the image file name in a db and tagging it for resizing. You could also put it in a resize_me directory that gets scanned by a daemon or cron job. You could have a daemon running and talk to it via a socket There's a lots of solutions. To me it seems silly to waste a fairly heavy mod_perl child (6-10 MB or memory perhaps) to resize an image in the background. The whole point of mod perl is to serve dynamic content, not to just be a generic processing mechanism. -Dave /*== www.urth.org we await the New Sun ==*/
Re: embperl-intermittant sig11 seg faults
if you need more info on how to reproduce it - let me know. Gerald Richter wrote: PROBLEM SOLVED. Fine :-) the values for $req_rec in the page and in the subs started out the same and then shifted after a period of time. That was my suspicion... I now pass in the $req_rec from the page to the subroutines and no more segfaulting. Thanks for the help. Is this a problem that you are going to correct with your code? If not, a gotcha in the documentation is warranted. It's a bug somewhere in Embperl, so I will correct it, but at the first shot I have to reproduce it here... Are there any related gotcha's that I should be aware of based upon the subroutine technique I am using? I am not aware of any. On another note - I install my site enmasse then restart apache so the mtime parameter should not be a factor when I execute the subroutine package. But you can simply leave out the mtime parameter and Embperl will make sure that it's cache correspond to the file on the filesystem. 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 -
Problems with mod_perl 1.2.1 and apache 1.3.9 - newbie - Please help!
I'm new to compiling my own software and attempting to get mod_perl and apache to work together. I have Redhat 6.0. I thought this was supposed to use gcc, not cc and I am getting no make action when it's done. I would _greatly_ appreciate any help on resolving this. I'm teaching myself Embperl and want it to have Virtual Logging. It appears that it must be a Apache module in order to enable this feature. I have the following directories in /usr/src mod_perl-1.21 apache_1.3.9 I just did gzip -d on the .gz files and then tar -xvf on the subsequent tar files. Then I went to the mod_perl-1.21 directory and did: $ perl Makefile.PL \ APACHE_PREFIX=/www \ DO_HTTPD=1 \ USE_APACI=1 \ EVERYTHING=1 makeout.log 21 Makeout.log is here: Will run tests as User: 'nobody' Group: 'root' Configuring for Apache, Version 1.3.9 + using installation path layout: Apache (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src + id: mod_perl/1.21 + id: Perl/5.00503 (linux) [perl] Creating Makefile in src + configured for Linux platform + setting C pre-processor to cc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + adjusting Apache build environment + enabling Perl support for SSI (mod_include) + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. This is most likely because your C compiler ** is not ANSI. Apache requires an ANSI C Compiler, such ** as gcc. The above error message from your compiler ** will also provide a clue. Aborting! Will configure via APACI cp apaci/Makefile.libdir ./apache_1.3.9/src/modules/perl/Makefile.libdir cp apaci/Makefile.tmpl ../apache_1.3.9/src/modules/perl/Makefile.tmpl cp apaci/README ../apache_1.3.9/src/modules/perl/README cp apaci/configure ../apache_1.3.9/src/modules/perl/configure cp apaci/libperl.module ./apache_1.3.9/src/modules/perl/libperl.module cp apaci/mod_perl.config ./apache_1.3.9/src/modules/perl/mod_perl.config cp apaci/mod_perl.config.sh ./apache_1.3.9/src/modules/perl/mod_perl.config.sh cp apaci/load_modules.pl.PL ./apache_1.3.9/src/modules/perl/load_modules.pl.PL cp apaci/find_source.PL ./apache_1.3.9/src/modules/perl/find_source.PL [everything snipped].enabled (cd ../apache_1.3.9 CC="cc" ./configure --activate-module=src/modules/perl/libperl.a --prefix=/www) Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl Then I ran make make.log 21 Make.log is here: (cd ../apache_1.3.9 make) make[1]: Entering directory `/usr/src/apache_1.3.9' === src make[2]: Entering directory `/usr/src/apache_1.3.9' make[3]: Entering directory `/usr/src/apache_1.3.9/src' make[3]: *** No rule to make target `all'. Stop. make[3]: Leaving directory `/usr/src/apache_1.3.9/src' make[2]: *** [build-std] Error 2 make[2]: Leaving directory `/usr/src/apache_1.3.9' make[1]: *** [build] Error 2 make[1]: Leaving directory `/usr/src/apache_1.3.9' make: *** [apaci_httpd] Error 2 -- Scott Chapman Technical Support Specialist Lund Performance Solutions [EMAIL PROTECTED] or [EMAIL PROTECTED] Phone: 541-926-3800 www.lund.com
Re: A few pointers, please.
[EMAIL PROTECTED] wrote: I'm fairly new at this and need a few pointers to possible resources. I've used Apache::AuthenDBI and thus require the user to enter a user name and password as expected. It all works. However, my customer has asked for either a timeout, a [Logout] button, or both so that the browser basically 'forgets' the user id. This would then remove the requirement for the user to close down the browser when they leave their system. Where can I look for assistence on this problem? My assumption is that it would be a 'browser' thing so I wouldn't expect a direct answer from this group. Due to the stateless nature of HTTP, a timeout is not quite possible with protocol level authentication. What you are wanting would either require a cookie or URL munging. Several modules exist on CPAN which can provide what you are looking for: Apache::AuthCookie Uses session keys to track users. Authentication appears to be restricted to one website. This code has been around a while and is more mature. Authen::Ticket Uses cookies to provide an authenticating ticket. The ticket may be signed using El Gamal (public key). Authenticating tickets may be presented to multiple websites. Newer code with bugs still being worked out. Both modules allow a high level of customization in most phases. Neither can handle mid-POST authentication yet. Both are similar, but with different emphasis. Both come with example code. -- James Smith [EMAIL PROTECTED], 409-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Jeffrey Baker wrote: 1) Visit /yoururl 2) Visit /yoururl?foo=barfoo=baz 3) Visit /yoururl as many times as you have Apache child processes httpd -X -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Apache::Cookie confusion
Apache::Cookie seems to have two different interfaces...or maybe there
are two different distributions of Apache::Cookie? Whatever it is, the
interface seems different on two machines here at work. One has 5.004
and one has 5.005, but that shouldn't change the Apache::Cookie interface
should it?
The interfaces are totally different. One uses set() and get(), either
from an object or via Apache::Cookie-get(). The other purports to
use the CGI::Cookie interface but only accepts the methods it documents
itself: fetch(), bake(), etc.
In my code, I "use Apache::Cookie" and then bang away trying to figure
out what methods it supports. The result is that the code on machine1
that calls Apache::Cookie-get('mycookie') dies with an undefined
subroutine error when run on machine2 (and vise versa for code on
machine2 that uses fetch() and bake()).
What am I missing here? I've done "force install Apache::Cookie"
from the CPAN shell prompt several time to try to make sure everything
is in sync, but the discrepancy still exists, and I still don't know
what the correct interface to Apache::Cookie should be. My hunch is
that the get() and fetch() versions are completely separate modules
that both declare "package Apache::Cookie", but good old CPAN should
allow that, should it?
Can someone set me straight?
-John
P.S.-Documentation snippets from the two machines:
On machine 1:
% perldoc Apache::Cookie
NAME
The Apache::Cookie module - An OO interface to cookies based
on CGI::Cookie, for use in mod_perl Apache modules.
SYNOPSIS
use Apache::Cookie;
$r = Apache-request;
# Object oriented
$cookie = Apache::Cookie-new($r);
$cookie-set(-name = 'cookie', -value = 'monster');
$value = $cookie-get('cookie');
...
On machine 2:
% perldoc Apache::Cookie
NAME
Apache::Cookie - HTTP Cookies Class
SYNOPSIS
use Apache::Cookie ();
my $cookie = Apache::Cookie-new($r, ...);
DESCRIPTION
The Apache::Cookie module is a Perl interface to the cookie
routines in libapreq. The interface is based on Lincoln
Stein's CGI::Cookie module.
...
Re: Apache::ASP config question
Brad Babb wrote: Hi, I'm about to put a site into production using Apache::ASP, and need to have a development side to the site to continue working. I won't to be able to have 2 difference Application, one for the production side, and one for the development side. What do I need to do to make this work. I tried something like this in httpd.conf, but didn't seem to work.. What didn't work about your config ? I'd also like to turn off all the debugging, etc, on the production side but like it on in the development side... Debug 0 for production. I may just be tired, (or dumb) and have missed something or just way off, but need help anyway.. If you want a separate Application, just set StateDir to something different. In your config, I didn't see a global set, which is very bad in production because then your state files will end up on Global/.state, which will be world readable, if Global is '.', the default setting. Note that you can use the same StateDir for both production development if you like, but not recommended, since you should isolate as much as possible the separate environments. Further degrees of isolation would include separate apache web servers, separate perl builds, ... (?) -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Bug in libapreq makes form elements stick to an apache child
[EMAIL PROTECTED] (Jeffrey Baker) wrote: Cliff Rayman wrote: `perldoc -f defined` yields a couple of sentences: You may also use Cdefined() to check whether a subroutine exists, by saying Cdefined func without parentheses. On the other hand, use of Cdefined() upon aggregates (hashes and arrays) is not guaranteed to produce intuitive results, and should probably be avoided. I hate it when that happens. why not use: if(@foo_in) instead of: if (defined @foo_in) Yeah. I guess the reason I do the latter is b/c I want the code to reflect what I am actually trying to test. I don't really want to test the trueness of @foo, I want to test for it's existence. But in perl the operation is overloaded. Feh. I think I will test for defined $foo_in[0] instead. Are you sure? I'm still not sure you understand about defined(@list). It actually tests whether Perl has allocated memory for the structure, not whether the structure has ever been used or anything like that. And even the present behavior may change without notice. When you do "my @list = func();" and func returns no values, @list will be an empty list. And it will evaluate in a boolean context to 0 (the number of elements), which is false. You shouldn't really care whether Perl has allocated memory to it or not, because different versions of Perl will give you different results with that test. Finally, what if func returns (undef, 1) or even (undef)? If you use your "defined $list[0]" test, you'll get a false result here, when func actually did return stuff. Of course, I don't know your specific application, but "defined @list" is one of the red flags of code. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Web Site Service Improvements
Question: Has anyone devlopped a Web Mail interface using perl? With mod_perl is there an available 'plug-in'?
Re: Bug in libapreq makes form elements stick to an apache child
"Jeffrey" == Jeffrey Baker [EMAIL PROTECTED] writes:
Jeffrey Yeah. I guess the reason I do the latter is b/c I want the code to
Jeffrey reflect what I am actually trying to test. I don't really want to test
Jeffrey the trueness of @foo, I want to test for it's existence. But in perl
Jeffrey the operation is overloaded. Feh.
Jeffrey I think I will test for defined $foo_in[0] instead.
"if (@foo) {...}" is *idiomatic* Perl for "are there any elements in
@foo, and if so, do this". If you don't understand the idioms, please
choose a more familiar language. :)
defined @bar and defined %bletch are almost never correct, and any
seasoned Perl hacker knows to watch for those as a red flag.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: A few pointers, please.
At 01:45 PM 11/19/99 -0500, [EMAIL PROTECTED] wrote: From: Dave Pfaltzgraff@PATAPSCO on 11/19/99 01:45 PM I'm fairly new at this and need a few pointers to possible resources. I've used Apache::AuthenDBI and thus require the user to enter a user name and password as expected. It all works. However, my customer has asked for either a timeout, a [Logout] button, or both so that the browser basically 'forgets' the user id. This would then remove the requirement for the user to close down the browser when they leave their system. Where can I look for assistence on this problem? My assumption is that it would be a 'browser' thing so I wouldn't expect a direct answer from this group. Exactly. The Basic Authentication scheme requires that the username and password be sent with each request; most browsers store this information after it has been entered once, and hang onto it until they are closed down. If you want to have a timeout or logout system, you need to implement some kind of session-based authentication. --- Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 ArtToday www.arttoday.com perl.apache.solaris.oracle "English is easy to learn -- all of the words are borrowed from C++"
Apache::ASP
I've written a short ASP page, 'HelloWorld.asp':
head
titleHello World/title
/head
Hello World! The time is % Now %
But when I try to test the page, I get the output below. Isn't Now a function
supported by ASP?
Errors Output
Response::Now not defined at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 2171
Apache::ASP::Response::AUTOLOAD('Apache::ASP::Response=HASH(0x83584a4)')
called at (eval 200) line 6
Apache::ASP::Demo::_home_webpages_userworld_htdocs_users_varocho1_asp_HelloWor
ld_aspINLINE() called at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 1051
eval {...} called at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 1051
Apache::ASP::Execute('Apache::ASP=HASH(0x8359c5c)') called at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 125
Apache::ASP::handler('Apache=SCALAR(0x8215d30)') called at /dev/null line
0
eval {...} called at /dev/null line 0
, /usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 1053
Debug Output
STARTING ASP HANDLER (v0.14) for file
/home/webpages/userworld/htdocs/users/varocho1/asp/HelloWorld.asp
GlobalASA package Apache::ASP::Demo
created $Application -
SessionCookie - 714a9dc4950f93a39d03dd1b6c9ce922
session timed out, clearing
Session_OnEnd - session: 714a9dc4950f93a39d03dd1b6c9ce922;
tieing session -
clearing starting session
forcing groups cleanup
group check GroupId71
skipping delete self - id: 714a9dc4950f93a39d03dd1b6c9ce922;
cleanup groups - deleted: 0;
Application_OnEnd
Application_OnStart
Session_OnStart - session: 714a9dc4950f93a39d03dd1b6c9ce922;
ASP object created - Application: Apache::ASP::Application=HASH(0x8359b9c);
GlobalASA: Apache::ASP::GlobalASA=HASH(0x839eda8); Internal:
Apache::ASP::State=HASH(0x8328334); Request:
Apache::ASP::Request=HASH(0x8359b54); Response:
Apache::ASP::Response=HASH(0x83584a4); Server:
Apache::ASP::Server=HASH(0x839e510); Session:
Apache::ASP::Session=HASH(0x8359de8); app_start: 0; basename: HelloWorld.asp;
buffering_on: 1; cgi_do_self: 0; cgi_headers: ; clean: 0; command_line: ;
compile_error: ; compile_includes: ; cookie_path: /; debug: 2; debugs_output:
ARRAY(0x839e408); dirname:
/home/webpages/userworld/htdocs/users/varocho1/asp; errors: 0; errors_output:
ARRAY(0x8282858); filehandle: ; filename:
/home/webpages/userworld/htdocs/users/varocho1/asp/HelloWorld.asp; filter: 0;
global: /home/webpages/userworld/htdocs/users/varocho1/asp/.; global_package:
Apache::ASP::Demo; group_refresh: 3; groups_refresh: 3; id:
_home_webpages_userworld_htdocs_users_varocho1_asp_HelloWorld_aspINLINE;
init_packages: ARRAY(0x839d184); mail_alert_period: 20; mail_alert_to: ;
mail_errors_to: ; mail_host: ; mtime: 943039109; no_cache: ; no_headers: 0;
no_session: 0; no_state: ; package: Apache::ASP::Demo; paranoid_session: 0;
pod_comments: 1; r: Apache=SCALAR(0x8215d30); remote_ip: 209.16.196.244;
script_timeout: 90; secure_session: ; session_serialize: ; session_timeout:
30; soft_redirect: ; stat_inc: 1; stat_inc_match: CGI; state_db: SDBM_File;
state_dir: /home/webpages/userworld/htdocs/users/varocho1/tmp/asp_demo;
state_manager: 10; ua: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98;
DigExt); unique_packages: 0;
parsing HelloWorld.asp
undefing sub
Apache::ASP::Demo::_home_webpages_userworld_htdocs_users_varocho1_asp_HelloWor
ld_aspINLINE active code CODE(0x8357ec8) before compiling
compiling into package Apache::ASP::Demo
Script_OnStart
executing
_home_webpages_userworld_htdocs_users_varocho1_asp_HelloWorld_aspINLINE
Response::Now not defined at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 2171
Apache::ASP::Response::AUTOLOAD('Apache::ASP::Response=HASH(0x83584a4)')
called at (eval 200) line 6
Apache::ASP::Demo::_home_webpages_userworld_htdocs_users_varocho1_asp_HelloWor
ld_aspINLINE() called at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 1051
eval {...} called at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 1051
Apache::ASP::Execute('Apache::ASP=HASH(0x8359c5c)') called at
/usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 125
Apache::ASP::handler('Apache=SCALAR(0x8215d30)') called at /dev/null line
0
eval {...} called at /dev/null line 0
, /usr/local/encap/perl-5.005.3/lib/site_perl/5.005/Apache/ASP.pm line 1053
Script_OnEnd
ASP to Perl Program
1: package Apache::ASP::Demo; ;; no strict; ;; use vars qw($Application
$Session $Response $Server $Request); ;; sub
Apache::ASP::Demo::_home_webpages_userworld_htdocs_users_varocho1_asp_HelloWor
ld_aspINLINE { ;; return(1) unless $_[0]; @_ = (); ;; $Response-Write('
2: head
3: titleHello World/title
4: /head
5:
6: Hello World! The time is '); Now $Response-Write('
7:
8: '); ;; }
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Matt Sergeant wrote: httpd -X good production solution.
