Re: .bml files not executing in apache

2002-07-23 Thread randy reed

Hi Randy,

Thanks for your reply. Please excuse my utter newbie status at all this. Ok,
looking at your message and the documentation for mod_perl as well as the LJ
documentation here's what I see.

BML is actually setup up as a perl module Apache::BML
its excuted in a file called modperl.pl  In httpd.conf there is a
PerlRequire c:/livejournal/cgi-bin/modperl.pl
but, as you can see if you try to get on my site
(www.thefreemachine.cc/index.bml) it doesn't excute. So whats missing that
would get httpd to call it when it receives a request for a .bml file. Is
there something I'm missing here (this is running on a windows machine), the
code seems fairly straightforward

PerlInitHandler +Apache::LiveJournal
DirectoryIndex index.html index.bml
});

unless ($LJ::SERVER_TOTALLY_DOWN)
{
Apache-httpd_conf(qq{
# BML support:
PerlSetVar BMLDomain lj-$LJ::DOMAIN
PerlModule Apache::BML
Perl
  Apache::BML::load_config(lj-$LJ::DOMAIN, $LJ::HOME/cgi-bin/bmlp.cfg);
/Perl
Files ~ \\.bml\$
  SetHandler perl-script
  PerlHandler Apache::BML
/Files
});
}

any help you could give would be greatfully appreciated.
Randy R





$r-path_info question

2002-07-23 Thread simran

Hi All, 

If i use hte following configuration:

apache.conf


Location /auto/thumbnails
  SetHandler  perl-script
  PerlHandler My::Thumbnails
/Location

Then in my handler sub in Thumbnails.pm do:
==

my $r = instance Apache::Reuest(shift);
print STDERR PathInfo: $r-path_info().\n;


Then i go to the url:
==

http://localhost/auto/thumbnails/images/a.gif


In my error log i get
==

PathInfo: /thumbnails/images/a.gif

However: if i create an 'auto' directory in my document root (something
that was not there before)

i get:

PathInfo: /images/a.gif

(which i like :-) 

Is this is feature or a bug, does path_info not check the 'Location' it
matced the handler to or is it meant to look at the directory structure?

simran.

  



Terminating an HTTP process

2002-07-23 Thread Mark Ridgway

Hi All,

We're running Mason 1.04 (Apache/1.3.22 (Solaris) mod_perl/1.26
mod_ssl/2.8.5 OpenSSL/0.9.6b) which connects to a number of Oracle
databases, so we are using Apache::DBI for connection pooling.

As we understand it, each process has its own connection pool that
lasts for the life of that process (i.e. each child collects its own
set of DB handles until it dies).

Whilst this is normally not an issue, when we experience network
problems, the number of available connections on some crucial databases
can quickly run out, which many open connections sitting idle in the
pool of various clients using other DBs, etc.

What we'd like to do is send some kind of quit signal to the process
so that it finishes that transaction and dies, instead of waiting until
MaxRequestsPerChild.  This will ensure that DB handles for this
particular DB will not be idly pooled, but instead constantly in use.

Is there a command to do this? (e.g. like 'abort', but one that
completes the transaction successfully, and kills the child process).
(e.g. $r-die() :-)

Also, does anyone know how to get the current RequestsPerChild
counter (that MaxRequestsPerChild evaluates against)?


Thanks!

Mark





Re: Terminating an HTTP process

2002-07-23 Thread Enrico Sorcinelli

On Tue, 23 Jul 2002 18:58:14 +1000
Mark Ridgway [EMAIL PROTECTED] wrote:

 Hi All,
 
 We're running Mason 1.04 (Apache/1.3.22 (Solaris) mod_perl/1.26
 mod_ssl/2.8.5 OpenSSL/0.9.6b) which connects to a number of Oracle
 databases, so we are using Apache::DBI for connection pooling.
 
 As we understand it, each process has its own connection pool that
 lasts for the life of that process (i.e. each child collects its own
 set of DB handles until it dies).
 
 Whilst this is normally not an issue, when we experience network
 problems, the number of available connections on some crucial databases
 can quickly run out, which many open connections sitting idle in the
 pool of various clients using other DBs, etc.
 
 What we'd like to do is send some kind of quit signal to the process
 so that it finishes that transaction and dies, instead of waiting until
 MaxRequestsPerChild.  This will ensure that DB handles for this
 particular DB will not be idly pooled, but instead constantly in use.
 
 Is there a command to do this? (e.g. like 'abort', but one that
 completes the transaction successfully, and kills the child process).
 (e.g. $r-die() :-)
 
 Also, does anyone know how to get the current RequestsPerChild
 counter (that MaxRequestsPerChild evaluates against)?
 

 


Hi Mark,
if you don't need persistent connections for all Oracle DBs
you can try to use some nonpersistent connections by setting
'dbi_connect_method' property to 'connect' in DBI connect
hash options:

  my $dbh = DBI-connect('dbi:...',... ,{'dbi_connect_method' = 'connect'});

However I think that the right solution is a connection pool server 
like SQLRealy (it work very well with Oracle, MySQL, PostgresSQL, DB2, etc)

Bye

Enrico

=
Enrico Sorcinelli - Gruppo E-Comm - Italia On Line S.p.a.
E-Mail: [EMAIL PROTECTED] - [EMAIL PROTECTED]
=



Re: $r-path_info question

2002-07-23 Thread darren chamberlain

* simran [EMAIL PROTECTED] [2002-07-23 05:11]:
 However: if i create an 'auto' directory in my document root
 (something that was not there before)
 

[-- snip --]

 Is this is feature or a bug, does path_info not check the 'Location' it
 matced the handler to or is it meant to look at the directory structure?

This is how Apache handles path_info: it is the extra stuff after
the translation handler has found a directory and filename.  It starts
at the left, and walks towards the right, until it finds the last
component that is a directory, and then the next piece is the file (no
existance check is done at this point).  The rest of it is path_info.

For example:

A request for /foo/bar/baz/quux, with a document root of /document/root
(assuming no Alias directives, that complicates things slightly), and
assuming that /document/root/foo is the last *directory* in the path
that exists, Apache does this:

  1. look for /document - yep
  2. look for /document/root - yep
  3. look for /document/root/foo - yep
  4. look for /document/root/foo/bar - nope

So /document/root/foo/bar is r-filename, and /baz/quux is path_info.

To reiterate: this is not a mod_perl thing (bug/whatever) but an Apache
one.

(darren)

-- 
An operating system is just a name you give the features you left
out of your editor.
-- Per Abrahamsen in comp.emacs



Change program name of httpd process

2002-07-23 Thread Oleg Shaikhatarov

Hello, all!

I need to change proctitle (called $PROGRAM_NAME or $0 in perl) of httpd
process from mod_perl. Simple change of $0 variable works well for
standalone perl program, but don't work under mod_perl. I'm not sure if
it's possible, but if anyone have an idea how to do this please help.

Regards,
Oleg Shaikhatarov
[EMAIL PROTECTED]






T switch is ignored modperl2.0

2002-07-23 Thread Kent, Mr. John

Greetings,

I have put PerlSwitches -T in my httpd.conf file,  yet keep getting the
following warning
in the server's error_log:

[Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with
'PerlSwitches -T' in httpd.conf

Any suggestions?

Thank you,

John Kent
Webmaster
Naval Research Laboratory
Monterey, CA



Re: T switch is ignored modperl2.0

2002-07-23 Thread Andy Lester

 I have put PerlSwitches -T in my httpd.conf file,  yet keep getting the
 following warning
 in the server's error_log:
 
 [Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with
 'PerlSwitches -T' in httpd.conf

You want the PerlTaintCheck On directive.

xoxo,
Andy

-- 
'Andy Lester[EMAIL PROTECTED]
 Programmer/author  petdance.com
 Daddy  parsley.org/quinn   Jk'=~/.+/s;print((split//,$)
[unpack'C*',n2]3%+\34.'%.'^%4+!o.'])



Re: Mail::Sender modperl.

2002-07-23 Thread Paul Lindner

Another chunk of sample code is available in chapter 15 of The
mod_perl Developer's Cookbook.  The Cookbook::Mail module uses
MIME::Lite and Email::Valid to send data/attachments around.

Feel free to adapt it to suit your needs:

http://www.modperlcookbook.org/code/ch15/Cookbook/Mail.pm

Regards

On Mon, Jul 22, 2002 at 10:48:52AM -0700, Goehring, Chuck Mr., RCI - San Diego wrote:
 Richard,
 
 I also use MIME::Lite (on Win2000) with mod_perl.  Found it to be quite reliable and 
it supports attachments and receipts like so:
 
   if($aReceipt ne '') {  # If return receipt requested.
 $msg-add(Disposition-Notification-To= $aApobj-getEmail_Address);  
   }
 
 Chuck
 
 -Original Message-
 From: Richard Clarke [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, July 20, 2002 6:28 AM
 To: [EMAIL PROTECTED]
 Subject: Mail::Sender  modperl.
 
 
 List,
 Have any of you had any problems using Mail::Sender from within 
 mod_perl. My script seems to just sit there waiting for $sender-Open to 
 do anything. I will email the author also but imagined he *might* not be 
 familiar with mod_perl so won't be able to offer any suggestions. 
 Anyone? I looked through the archives but saw no reference to a problem 
 like this. Some people indicated much success with Mail::Sender (not so 
 for me however!).
 
 Second, the recommended solution for sending mails is to instead put 
 them on a queue for an external daemon to handle. My question is, is 
 there a standard implementation people use when doing this. Is the KISS 
 theory invoked and the outoing mail simply written to some plain text 
 spool file or do people use something more involved like writing the 
 to,cc,from,subject,body test to a database and storing any temporary 
 files (attachment) in a directory for later encoding?
 
 Ric
 
 p.s. here is an excerpt from my apache log indicating precisely what happens
 
   220 mail.likewhoa.com ESMTP Postfix
 421 Error: timeout exceeded
  ehlo localhost
  mail from: [EMAIL PROTECTED]
  rcpt to: [EMAIL PROTECTED]
  data
  To: [EMAIL PROTECTED]
  From: [EMAIL PROTECTED]
  X-Mailer: Perl script null
   using Mail::Sender 0.7.14.1 by Jenda Krynicky
   running on localhost (127.0.0.1)
   under account root
  Date: Sat, 20 Jul 2002 13:18:12 -
  Message-ID: [EMAIL PROTECTED]
  Subject:  msg msg msg
 
 close sender
 
  .
  quit
 done
 The request took 305.710375070572 seconds

-- 
Paul Lindner[EMAIL PROTECTED]   | | | | |  |  |  |   |   |

mod_perl Developer's Cookbook   http://www.modperlcookbook.org/
 Human Rights Declaration   http://www.unhchr.ch/udhr/



Mod Perl build problem with perl 5.8.0

2002-07-23 Thread David McCabe

I am having a problem building mod_perl with the new perl 5.8.0. This does not
occur with perl 5.6.1. (All DSO, BTW)

I build using the CPAN module, with a .makepl_args.mod_perl file in my $HOME
dir. This has worked just fine for years, through multiple versions of perl,
mod_perl, Apache, and Solaris.

Now, when the make test of mod_perl is run, I see this:

internal/http-get.Internal Server Error
internal/http-get.dubious
Test returned status 29 (wstat 7424, 0x1d00)
DIED. FAILED tests 1-16
Failed 16/16 tests, 0.00% okay
internal/http-postInternal Server Error
internal/http-postdubious
Test returned status 29 (wstat 7424, 0x1d00)
DIED. FAILED tests 1-7
Failed 7/7 tests, 0.00% okay

All other tests pass just fine,

And in the error_log, I see these: (besides the 'expected' errors)

[Tue Jul 23 10:48:15 2002] [error] Undefined subroutine Apache::exit called at
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test line
129, fh1b chunk 1.

print() on closed filehandle FH at
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl
line 15, fh1b line 1.
print() on closed filehandle FH at
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl
line 26, fh1b line 1.
[Tue Jul 23 10:48:16 2002] [error] can't open
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/docs/.htaccess at
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/hooks.pl
line 51, fh1b line 1.

[Tue Jul 23 10:48:18 2002] [error] END block was not run for
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test

[Tue Jul 23 10:48:20 2002] [error] END block was not run for
/opt/.cpan/build-5.8.0-mod-perl-Apache-1.3.26/mod_perl-1.27/t/net/perl/test

This is with perl 5.8.0, mod_perl 1.27, Apache 1.26, and Solaris 8. I build all
this from source, (except Solaris!!:), using gcc 2.95. Apache is compiled with
these options passed to Configure by the .makepl_args.mod_perl file: ( as well
as some site-specific options, like --prefix=, etc)

--enable-module=all --enable-shared=max --disable-module=example
--disable-module=auth_db --verbose --server-uid=httpd --server-gid=www

(the auth_db module will not build with Berkeley DB 4.x, which is what I have to
use for other apps on the same machine. Fortunately, I do not use that module,
so I don't care. :)

perl -V:

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos rapier 5.8 generic_108528-14 sun4u sparc sunw,sun-blade-100 '
config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc
-Dloclibpth=/opt/BerkeleyDB/lib -Uinstallusrbinperl
-Dprefix=/opt/perl5.8.0-mod-perl-Apache-1.3.26
-Dscriptdir=/opt/perl5.8.0-mod-perl-Apache-1.3.26/scripts
[EMAIL PROTECTED] -Dldflags=-R/opt/BerkeleyDB/lib:/opt/lib
-Dmydomain=.mcgill.ca -Dmyhostname=rapier [EMAIL PROTECTED]
-Dlocincpth=/opt/BerkeleyDB/include -Dcf_by=David McCabe -d'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -I/opt/BerkeleyDB/include',
optimize='-O',
cppflags='-fno-strict-aliasing -I/opt/BerkeleyDB/include'
ccversion='', gccversion='2.95.3 20010315 (release)',
gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, prototype=define
  Linker and Libraries:
ld='gcc', ldflags ='-R/opt/BerkeleyDB/lib:/opt/lib -L/opt/BerkeleyDB/lib'
libpth=/opt/BerkeleyDB/lib /usr/lib /usr/ccs/lib /usr/local/lib
libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -R/opt/BerkeleyDB/lib:/opt/lib
-L/opt/BerkeleyDB/lib'


Characteristics of this binary (from libperl): 
  Compile-time options:
  Built under solaris
  Compiled at Jul 22 2002 12:12:58
  @INC:
/opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/McGill/sun4-solaris
/opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/McGill
/opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/5.8.0/sun4-solaris
/opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/5.8.0
/opt/perl5.8.0-mod-perl-Apache-1.3.26/lib/site_perl/5.8.0/sun4-solaris

possible buget in CGI.pm

2002-07-23 Thread Greg_Cope

Hi All,

We are implementing mod_perl here for internal intranet use.  We have
discovered a possible buglet in CGI.pm.

We do not want CGI.pm to return XHTML as it upsets Verity indexing (long
story).

So in Apache::Registry executed scripts we use:

use CGI qw( -no_xhtml );

But on the first invocation it returns normal HTML.  On second invocation it
ignores this directive and returns XHTML.  We started a dev server with -X
to confirm this.  It would appear CGI resets its globals somewhere.

Can someone confirm this?

Also is this the right forum for this ?

Which bit of the plot have I missed?

Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81

Thanks,

Greg Cope



This message and any attachment has been virus checked by
Pfizer Corporate Information Technology, Sandwich.





ANNOUNCE: Mason 1.12

2002-07-23 Thread Dave Rolsky

This release has a number of important improvements and it is highly
recommended that anyone use Mason 1.10 or 1.11 upgrade immediately in
order to fix a nasty memory leak in ApacheHandler.  1.12 is also quite a
bit faster than previous 1.1x versions.

Those folks still using 1.0x or earlier should upgrade if they want to
play with new features, but should not that there are a number of
backwards incompatibilities in the newest versions, so if you have working
code in production that you don't want to change, don't upgrade!

With that said, here are the changes for 1.12:

1.12

[ ENHANCEMENTS ]

- Various optimizations have been added to this release in order to
address the fact that Mason 1.11 is quite a bit slower than 1.05.  One
major factor was optimizing Params::Validate and Class::Container, so
for that reason this version of Mason requires Params::Validate 0.24
and Class::Container 0.07.  With these modules installed, this release
shows improvements of up to 50-60% in benchmarks that stress Mason's
weaknesses, with other benchmarks showing up to a 100% improvement.
- Made subclassing CGIHandler more useful by breaking out its arg
processing into a request_args method, just like ApacheHandler.
- Added alter_superclass method to Request class, for use by Request
subclasses.  See the HTML::Mason::Subclassing document for details.

[ BUG FIXES ]

- Fix HTML generated for error messages so that tags balance out.
Unbalanced table tags caused this page to not display properly with
Netscape 4.x.
- Fix nasty memory leaks in ApacheHandler.






Re: possible buget in CGI.pm

2002-07-23 Thread darren chamberlain

Hi,

* [EMAIL PROTECTED] [EMAIL PROTECTED] [2002-07-23 11:26]:
 We are implementing mod_perl here for internal intranet use.  We have
 discovered a possible buglet in CGI.pm.
 
 We do not want CGI.pm to return XHTML as it upsets Verity indexing
 (long story).

So sorry to hear about that.

 So in Apache::Registry executed scripts we use:
 
   use CGI qw( -no_xhtml );
 
 But on the first invocation it returns normal HTML.  On second
 invocation it ignores this directive and returns XHTML.  We started a
 dev server with -X to confirm this.  It would appear CGI resets its
 globals somewhere.
 
 Can someone confirm this?

Yes:

  From CGI.pm, version 2.81:

 35 #  Here are some globals that you might want to adjust 
 36 sub initialize_globals {
 37 # Set this to 1 to enable copious autoloader debugging messages
 38 $AUTOLOAD_DEBUG = 0;
 39 
 40 # Set this to 1 to generate XTML-compatible output
   41 $XHTML = 1;
 42 
 43 # Change this to the preferred DTD to print in start_html()
 44 # or use default_dtd('text of DTD to use');
 45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
 46  'http://www.w3.org/TR/html4/loose.dtd' ] ;
 47 

Judging from line 35 you might want to adjust some of those globals.

If you are using CGI in the OO way, you can just subclass CGI:

  package My::CGI;

  use base qw(CGI);
  sub initialize_globals {
  CGI::initialize_globals();
  $CGI::XHTML = 0;
  }

And then:

  my $q = My::CGI-new;

Of course, I haven't tested this.

Another option is to call:

  CGI-import(-no_xhtml);

at the top of your Registry script, which will be executed every time,
whereas the use CGI qw( -no_xhtml ); is only being called at compile
time.

(darren)

-- 
You can put a man through school, but you cannot make him think.
-- Ben Harper



mod_perl with a perl built with -Dusethreads, will it work?

2002-07-23 Thread Brian

I would like to install Sendmail::Milter which needs a perl built 
with thread support.  Last time I tried to use a perl built with 
thread support (5.6.x), mod_perl didn't like it.  Is this still the 
case with 5.8.0? Is anybody using mod_perl with a perl built with 
-Dusethreads?

Thanks,

Brian

--
Linux 2.4.18
libc 2.1.3
apache 1.3.26
mod_perl 1.27




RE: possible buget in CGI.pm

2002-07-23 Thread Greg_Cope

 -Original Message-
 From: darren chamberlain [mailto:[EMAIL PROTECTED]]
  Can someone confirm this?
 
 Yes:
 

Good I'm not mad :-)

   From CGI.pm, version 2.81:
 
  35 #  Here are some globals that you might want to 
 adjust 
  36 sub initialize_globals {
  37 # Set this to 1 to enable copious autoloader 
 debugging messages
  38 $AUTOLOAD_DEBUG = 0;
  39 
  40 # Set this to 1 to generate XTML-compatible output
41 $XHTML = 1;
  42 
  43 # Change this to the preferred DTD to print in 
 start_html()
  44 # or use default_dtd('text of DTD to use');
  45 $DEFAULT_DTD = [ '-//W3C//DTD HTML 4.01 Transitional//EN',
  46  
'http://www.w3.org/TR/html4/loose.dtd' ] ;
 47 

Judging from line 35 you might want to adjust some of those globals.

If you are using CGI in the OO way, you can just subclass CGI:

  package My::CGI;

  use base qw(CGI);
  sub initialize_globals {
  CGI::initialize_globals();
  $CGI::XHTML = 0;
  }

And then:

  my $q = My::CGI-new;

Of course, I haven't tested this.

Another option is to call:

  CGI-import(-no_xhtml);

at the top of your Registry script, which will be executed every time,
whereas the use CGI qw( -no_xhtml ); is only being called at compile
time.


Lookout has givenup putting the ''s in!. grh

Thanks for those Darren, 

With out wishing to be rude, the above are all workarrounds the bug (ie it
should not overide the -no_xhtml pragma), and we've used our own.

The subclssing one was good thou! and I did not know the CGI-import one.

Thanks,

Greg

(darren)

-- 
You can put a man through school, but you cannot make him think.
-- Ben Harper



This message and any attachment has been virus checked by
Pfizer Corporate Information Technology, Sandwich.





Re: possible buget in CGI.pm

2002-07-23 Thread Lincoln Stein

I'm aware of the problem, but I haven't been able to track it down.  Any help 
is welcome.

Lincoln

On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote:
 Hi All,

 We are implementing mod_perl here for internal intranet use.  We have
 discovered a possible buglet in CGI.pm.

 We do not want CGI.pm to return XHTML as it upsets Verity indexing (long
 story).

 So in Apache::Registry executed scripts we use:

   use CGI qw( -no_xhtml );

 But on the first invocation it returns normal HTML.  On second invocation
 it ignores this directive and returns XHTML.  We started a dev server with
 -X to confirm this.  It would appear CGI resets its globals somewhere.

 Can someone confirm this?

 Also is this the right forum for this ?

 Which bit of the plot have I missed?

 Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81

 Thanks,

 Greg Cope


 
 This message and any attachment has been virus checked by
 Pfizer Corporate Information Technology, Sandwich.
 



Mail programmes using .htpasswd to verify username/password access

2002-07-23 Thread The Doctor

Does anyone know of such a programme?
-- 
Member - Liberal International  On 11 Sept 2001 the WORLD was violated.
This is [EMAIL PROTECTED]   Ici [EMAIL PROTECTED]
Society MUST be saved! Extremists must dissolve.  
Beware of defining as intelligent only those who share your opinions



Re: possible buget in CGI.pm

2002-07-23 Thread mike808

 On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote:
  We do not want CGI.pm to return XHTML ...
  So in Apache::Registry executed scripts we use:
  use CGI qw( -no_xhtml );
  But on the first invocation it returns normal HTML.  On second invocation
  it ignores this directive and returns XHTML.  We started a dev server
  with -X to confirm this.  It would appear CGI resets its globals
  somewhere.
...
  Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81

On Tuesday 23 July 2002 12:47 pm, Lincoln Stein wrote:
 I'm aware of the problem, but I haven't been able to track it down.  Any
 help is welcome.

Lincoln, Greg, mod_perl list:

The problem appears to be that the -no_xhtml option is only processed in
_setup_symbols. This is called only during import() and compile(), and sets 
$XHTML appropriately.

However, $XHTML is reset to 1 in initialize_globals(). _reset_globals() is an 
alias for this as well. initialize_globals() is called only once in the 
startup  execution (has a comment Make mod_perl happy) of the module.

However, _reset_globals is called during new(), and is registered with 
mod_perl as a cleanup handler.

What this means is that after the first execution, the cleanup handler fires 
and _reset_globals() is called, which calls initialize_globals(), which then 
sets the global $XHTML to 1. QED.

It looks like -nosticky suffers from the same fate as well, and I would 
venture to guess that all of the variables reset in initialize_globals() are 
not being set properly according to the values parsed in _setup_symbols().
e.g. $NPH, $NOSTICKY, $DEBUG, $HEADERS_ONCE, etc.

I think the 'undef $NPH' in new() was an attempt to address this for that 
variable. But it still leaves the rest out in the cold.

Because _setup_symbols eats the parameters (the options passed in on the 'use' 
line), there's no way to call it again later in new() since it ran at compile 
time.

One might preserve the options passed in to _setup_symbols() and then
have new() call it again with those options to make sure that the new instance 
retains the options set on the 'use' line. LDS, You might want to separate 
the option parsing from the autoload magic in _setup_symbols(), and just call
the option parsing part with the saved options from the 'use' line in the 
cleanup handler.

Mike808/
-- 
() Join the ASCII ribbon campaign against HTML email and Microsoft-specific
/\ attachments. If I wanted to read HTML, I would have visited your website!
Support open standards.