Re: PerlInitHandler and PerlSetEnv
> > > > There is no "directory, .htaccess" in the context and that's like it really > > behaves. (unless they changed it in a very recent version and didn't update > > the docs, which I don't expect) > > > > PerlSetEnv is the only chance to have different values in different > > directories. > > i think the docs are out-of-date, seems to work inside location: > Doug, you are right. It apears in the Apache CHANGES file for 1.3.7, but the docs still not updated Gerald P.S. I have made a bug report, so hopefully the docs will get updated also - 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 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: push_handlers and PerlAuthenHandler troubles [second try]
On Tue, 26 Jun 2001, Bolt Thrower wrote:
> My apologies if you've seen this twice.
>
> For a particular Location, I'd like to selectively (i.e., based on
> arbitrary criteria) determine whether a visitor needs authentication.
> So I set up a Location section in httpd.conf as follows:
> PerlAuthenHandler Intranet::CheckSiteAuthen
> #PerlAuthenHandler Apache::AuthTicket->authenticate
> package Intranet::CheckSiteAuthen;
...
> sub handler {
> my $r = shift;
> $r->warn("starting CheckSiteAuthen");
> $r->push_handlers(PerlAuthenHandler =>
> 'Apache::AuthTicket->authenticate');
in the current sources, you cannot push a handler in the current
phase. you could use a PerlAccessHandler to push the PerlAuthenHandler
instead.
Re: swapping of mod_perl parent process / mlockall()
On Tue, 26 Jun 2001, Adi Fairbank wrote: > > Is it correct that when the Apache/mod_perl parent process swaps to disk, a > large part of it (swapped pages) becomes unshared? Even after the kernel > restores the pages from swap, do they remain unshared? So once the parent > process becomes unshared, new apache children that are spawned only share > the parent's pages that have never been swapped? > > This is what I've grok'ed from my experiments with top/GTop. > > If this is the case, it would be helpful to prevent the parent process from > *ever* swapping to disk. > > The Linux kernel has a system call mlockall() which disables all memory > paging for the current process. This sounds like exactly the recipe for > preventing parent process swapping. It won't affect spawned child > processes, so shouldn't pose a threat of consuming all physical memory and > crashing the system. > > I want to play around with this, but I'm not sure where in the mod_perl > source to call mlockall(). It would need to be before the parent spawns any > children.. Has anyone tried using Linux's mlockall()/mlock() with mod_perl? according the manpage: "Child processes do not inherit page locks across a fork." so you would need to call it in a child init handler, but: "Only root processes are allowed to lock pages."
Re: help about ap_pool in Perl
On Tue, 10 Jul 2001, Alberto Canzi wrote: > > Hi I need to use the ap_pool structure. In my Apache Module writing book > is explained how to use it in C but nothing is said about using it in > Perl. > > How does it work ? How may I use it in Perl? what do you need to use it for from Perl? much of the Perl api uses ap_pool underneath, and certain functions are exposed, such as register_cleanup, but normally you shouldn't need to use it directly from Perl.
Re: duplicate libperl.so causes problems on Tru64
On Tue, 10 Jul 2001, Dave Hill wrote: > > Hi, > I am using mod_perl-1.25_01 on Tru64 unix with apxs. > > The default packaging creates the DSO mod_perl as libperl.so. This > causes problems on Tru64 unix as the loader cannot differentiate between > libperl.so which is part of the PERL distribution and libperl.so which > is the Apache DSO. > > I found the replacing libperl in apaci/Makefile with mod_perl (4 > places) solved this issue. > > Given that Apache seems to use mod_*.so for library names. why not > with mod_perl ? > If that does not make sense, how about adding a variable that could e > used with Makefile.PL ? mainly historical reasons. mod_perl followed the mod_proxy convention of nameing multi-source-file modules libname.a, which php does as well, probably others too. at the time the lib$name had to match the $name_module structure for apache's build system to get things right. the name stuck when dso was introduced. you can always rename modperl's libperl.so to libmodperl.so or whatever. 2.0 uses that name to avoid this confict/confusion and also allows you to name it whatever you like with a Makefile.PL option. i'd be happy to have a Makefile.PL option for 1.xx if you want to submit a patch, but the default will probably stay libperl.so for 1.xx.
Re: Knowing the current VirtualHost at server startup
On Tue, 10 Jul 2001, Robin Berjon wrote:
> Hi,
>
> I've been looking around for a way for a section (or code called from
> it, or perhaps even loaded through PerlModule) to know the current
> VirtualHost in which it is, at server startup (ie without a request object
> handy).
>
> Apache->server returns the main server object (or so it seems, that would
> appear to be logical) and I know that I can use $s->next to get a chain of
> server objects, but I can't seem to find a way in C or in Perl to know about
> the current server.
Apache->server will point to the current VirtualHost with this patch..
--- src/modules/perl/perl_config.c 2001/06/19 03:12:45 1.110
+++ src/modules/perl/perl_config.c 2001/07/11 02:46:32
@@ -1744,7 +1744,15 @@
ENTER_SAFE(parms->server, parms->pool);
MP_TRACE_g(mod_perl_dump_opmask());
-perl_eval_sv(code, G_DISCARD);
+
+{
+SV *server_sv = perl_get_sv("Apache::__SERVER", FALSE);
+IV ptr = SvIVX(SvRV(server_sv));
+SvIVX(SvRV(server_sv)) = (IV)parms->server;
+perl_eval_sv(code, G_DISCARD);
+SvIVX(SvRV(server_sv)) = (IV)ptr;
+}
+
LEAVE_SAFE;
{
boot_IO error
Hello. I've searched the internet and found many things relating to this, but I thought I would present my own specific problem. I'm trying to install mod_perl with IBM HTTP Server (which is really just apache 1.3.12) on AIX 4.3.3. Everything installs fine, but when I tried to use Net::LDAP, apache segfaults. When I analyze the core file, I'm told that boot_IO is where the problem occurred. Has anyone conquered this problem? The mod_perl readme says that if you are installing on AIX with perl 5.00503 you have to apply a patch to prevent segfaulting when an XS module is called. I applied it and re-compiled. I also tried using perl 5.6.1, which yielded the same results. I've traced it down to the 'use IO::Handle;' clause. I'm using the VisualAge C (vac) compiler to compile everything (gcc hasn't worked very well for most things on this platform.) The following details the method to my madness: # lslpp -l |grep vac vac.msg.en_US.C5.0.1.0 COMMITTED C for AIX Compiler Messages - vacpp.cmp.rte 4.0.2.0 COMMITTED VisualAge C++ Compiler vac.C 5.0.1.0 COMMITTED C for AIX Compiler # lslpp -l |grep xlC xlC.aix43.rte 4.0.2.2 APPLIEDC Set ++ Runtime for AIX 4.3 xlC.cpp4.3.0.1 COMMITTED C for AIX Preprocessor xlC.msg.en_US.cpp 4.3.0.1 COMMITTED C for AIX Preprocessor xlC.msg.en_US.rte 4.0.2.0 COMMITTED C Set ++ Runtime xlC.rte4.0.2.0 COMMITTED C Set ++ Runtime # cd /usr/build/perl_5.00503 # ./Configure -de # make # make install # perl -MCPAN -e shell; (answer configuration questions...) cpan> install HTML::HeadParser cpan> install LWP::UserAgent # cd /usr/build/mod_perl-1.25 # perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/HTTPServer/bin/apxs EVERYTHING=1 # make # make install # cd /usr/HTTPServer/bin # ./apachectl configtest Syntax OK At this point, lots of perl scripts will run fine under mod_perl, until one of them calls 'use IO::Handle;' ... then: # ./apachectl configtest ./apachectl[145]: 19372 Segmentation fault(coredump) Now I analyze the core file to find out what is causing the dump.. surprise! # dbx /usr/HTTPServer/bin/httpd core Type 'help' for help. reading symbolic information ...warning: no source compiled with -g [using memory image in core] Segmentation fault in boot_IO at 0xd178d39c ($t1) 0xd178d39c (boot_IO+0xc) 8083lwz r4,0x0(r3) Thinking it might be IBM HTTP Server implimentation, I built apache from source with the following method (I did this with Apache 1.3.12 and Apache 1.3.20): # cd /usr/build/apache_1.3.12 # ./configure --enable-module=so \ --enable-module=proxy \ --enable-shared=proxy \ --prefix=/usr/local/apache # make # make install Then I repeated the mod_perl installation. Same darn segfault. This is what my perl -V looks like: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=aix, osvers=4.3.3.0, archname=aix uname='aix funny 3 4 01716600 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O', gccversion= cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384' ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='-s' libpth=/lib /usr/lib /usr/ccs/lib libs=-lnsl -ldbm -ldl -lld -lm -lc -lcrypt -lbsd -lPW -lC_r libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='-bE:perl.exp' cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE -bI:$(PERL_INC)/perl.exp -bE:$(BASEEXT).exp -b noentry -lc' Characteristics of this binary (from libperl): Built under aix Compiled at Aug 14 1999 08:59:55 @INC: /usr/opt/perl5/lib/5.00503/aix /usr/opt/perl5/lib/5.00503 /usr/opt/perl5/lib/site_perl/5.005/aix /usr/opt/perl5/lib/site_perl/5.005 Does anyone have any insight into this? It's becoming a very painful battle. Thanks, Matt Glosson
Re: send_httpd_headers
On Tue, 10 Jul 2001, Doug MacEachern wrote:
> unless ($r->header_in('Content-type')) {
i meant header_out, not header_in
Re: can't start apache-1.3.20 with mod_perl and Mason
On Mon, 9 Jul 2001, Louis-David Mitterrand wrote: > Hi, > > After "upgrading" my installation to Apache-1.3.20 and mod_perl-1.25 as > as a module I can't start apache anymore when httpd.conf contains: > > PerlRequire /etc/apache/perl/handler.pl > > And that file (for debugging purposes) is practically empty: > > #!/usr/bin/perl > package HTML::Mason; > > use strict; > use HTML::Mason; > use HTML::Mason::ApacheHandler; > 1; > > Running "strace apache -X" shows: > > read(3, "ETE PATCH PROPPATCH MKCOL COPY M"..., 4096) = 4096 > read(3, "mLog directive (see below).\n#\nLo"..., 4096) = 4096 > read(3, "n /icons/uuencoded.gif .uu\nA"..., 4096) = 4096 > read(3, " tweak mime.types without actual"..., 4096) = 4096 > --- SIGSEGV (Segmentation fault) --- > +++ killed by SIGSEGV +++ see mod_perl-1.25/SUPPORT for hints on howto get a stacktrace.
Re: send_httpd_headers
On Sun, 8 Jul 2001, Brooklyn Linux Solutions CEO wrote:
> Is there a way to know that headers have already been sent
> before send headers out?
you can check for things that should be empty until send_http_header is
called, e.g.
unless ($r->header_in('Content-type')) {
#header has not been sent
}
unless ($r->status_line) {
#header has not been sent
}
Re: upgrading mod_perl/CGI.pm shows some weirdness
On 6 Jul 2001, Peter Rooney wrote: > machine 1: > CGI.pm version 2.46 > machine 2 (the new machine): > CGI.pm version 3.02 3.02 is alpha, the README says: Version 3 of CGI.pm is in alpha state. It has significant performance improvements over the 2.X series, but is not stable. If you find a bug, please track it down, fix it, and send me the patch. i would send lincoln and report and stick with the 2.xx version for production.
Re: Possible bug with ModPerl 1.25 and Escape_uri
On Fri, 6 Jul 2001, Stef Telford wrote: > Hello, > I hope this is the right place to put this. I have some code that takes data > from a database and encrypts it via Blowfish and CBC. Not a problem so far, > the problems comes with sending it to the client. ... > Now, if i look at the string (and ignoring all the strange characters that > slip through escape_uri) i cant help but notice that escape_uri 'breaks' on > the character after %99G which, lo and behold, is %00 which says to me that > for some reason CGI::Cookie does the 'right thing' in the case of Blowfish > encrypted text, but escape_uri in mod_perl doesnt. looks like apache's uri escape code does not properly handle binary data. one solution would be base64 encode your $ciphertext before using it to create the cookie, then decode it after fetching the cookie. you can use MIME::Base64 for this, which is fairly lightweight.
Re: nothing-or-all behave of perl module
I'm no expert but I believe if you do what you want to do and return DECLINED apache will pick it up from there. According to the book Writing Apache Modules with Perl an C: "DECLINED The handler has decided it doesn't want to handle the request. Apache will act as if the subroutine were never called and either handle the phase internally or pass the request on to another module that has expressed interest. Even if all registered modules return DECLINED for a particular phase, it will still be handled by the apache core, which has handlers for each phase( even if they do nothing)." more to the same effect. The book is well worth the price. Check it out. Mike - Original Message - From: "Surat Singh Bhati" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, July 10, 2001 5:38 PM Subject: nothing-or-all behave of perl module > hi members, > > While we use a perl handler at any stage handle that > apache phase using our module, can Apache do its all default > processing for the same stage, or it works on nothing-or-all > approchm. > > I want to modify the PerlTransHandler slightly, but I dont > want to rewrite all the processing done by Aapche in perl > module. Can I forward the default processing to Apache > handle again for the same stage. OR can I insert my custom handler > between any two stage of apache. > > I means, at TransHandler , first I want to do some processing > using the PerlTransHandler , then let the Apache do all the > task of TransHandler (sort of stack handler) > > Is is possible? > > Reagards, > > -Surat Singh Bhati > > > > > > > > > > > >
nothing-or-all behave of perl module
hi members, While we use a perl handler at any stage handle that apache phase using our module, can Apache do its all default processing for the same stage, or it works on nothing-or-all approchm. I want to modify the PerlTransHandler slightly, but I dont want to rewrite all the processing done by Aapche in perl module. Can I forward the default processing to Apache handle again for the same stage. OR can I insert my custom handler between any two stage of apache. I means, at TransHandler , first I want to do some processing using the PerlTransHandler , then let the Apache do all the task of TransHandler (sort of stack handler) Is is possible? Reagards, -Surat Singh Bhati
Re: [ModPerl] missing POST args mystery
Ed Loehr wrote: > > > >I'm stumped ... > > >In a nutshell, my problem is that POSTed form key-value pairs are > > >intermittently not showing up in the request object inside my handler > > >subroutine. As I was puzzling over this, I saw this error message in the logs... (offline mode: enter name=value pairs on standard input) A google search turned up a note about needing to have "$CGI::NO_DEBUG = 1" before calling CGI::Cookie->parse(). Adding that line of code before my parse call seems to have fixed the problem. At a glance, looks like CGI.pm was strangely set to read from the command-line (default $CGI::NO_DEBUG = 0), probably triggering a call of Apache's request->args somewhere along the line. How the default setting may have changed I don't know, because I've been using CGI.pm for years without this problem; I may have upgraded that package, picking up a change accidentally. Regards, Ed Loehr
duplicate libperl.so causes problems on Tru64
Hi, I am using mod_perl-1.25_01 on Tru64 unix with apxs. The default packaging creates the DSO mod_perl as libperl.so. This causes problems on Tru64 unix as the loader cannot differentiate between libperl.so which is part of the PERL distribution and libperl.so which is the Apache DSO. I found the replacing libperl in apaci/Makefile with mod_perl (4 places) solved this issue. Given that Apache seems to use mod_*.so for library names. why not with mod_perl ? If that does not make sense, how about adding a variable that could e used with Makefile.PL ? regards, Dave Hill -- +-oOO--(_)--OOo+ |Dave Hill(0 0)Unix Software Group | |Mailstop: ZKO3-2/W17 \//\/| |Digital Equipment Corp. (603 )884-2985 | |110 Spitbrook Road /\//\enet: [EMAIL PROTECTED]| |Nashua, NH 03062-2698(0_0)| +-oOO--(_)--OOo+
Re: Apache::SimpleTemplate (don't do it!)
At 20:19 09.07.01 +0200, you wrote: >It's your decision, but I think you waste your time while you make all the >experiences the other had made during the last 3-5 years. I think it would >more helpfull if you help to improve the other modules (for example makeing >them easier to install etc.) >...but I know that's useless to say, mostly everybody has to write his own >templating solution... > >Gerald > >P.S. I guess we would have much better ones, if we don't have hundreds of >them all doing nearly the same ! The reason is IMHO that it is easy to write a simple template engine. It is nearly as easy as understanding one by reading docs and sources. And it is easier than understandig 3 or 4 of them to find one that matches several needs. And contributing to an existing one is the hardest. Joachim -- "... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen."- Bertolt Brecht - Leben des Galilei
Re: !!!reevaluating part of the module
raptor wrote:
>
> hi,
>
> What I want is access from module to executed-at-the-moment script namespace
> i.e.
>
> the module Utils.pm :
>
> $"abc.asp"::buffer .= 'hello.';
>
> PS. It seems to work only if into the script I'm clearing $Utils::buffer at
> the begining of the script, but this is exactly what I don't want to do...
> want this to be done from outside... code reuse i say :"). It doesn't matter
> too much to me where is the $buffer variable in Utils or in the script
> name-space, I just don't want to clear it out manualy every time in the
> script...
>
It looks like you are using ASP, did you know that $Response->Write()/print()
has its own buffering if you have BufferingOn set ? If you used print()
by itself, then you might have the most flexibility if you are looking
at porting issues.
To answer your question specifically, you can do a
Apache->register_cleanup(sub { $Utils::buffer = '' } );
or the same with ASP $Server->RegisterCleanup()... or
you could do this in ASP global.asa Script_OnStart too,
but you have to do it at some point. You might
also have some function called Utils->init_buffer() which
you could call to do this, and declare buffer as a my()
in Utils so no other package could possibly access it.
-- Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Knowing the current VirtualHost at server startup
Hi, I've been looking around for a way for a section (or code called from it, or perhaps even loaded through PerlModule) to know the current VirtualHost in which it is, at server startup (ie without a request object handy). Apache->server returns the main server object (or so it seems, that would appear to be logical) and I know that I can use $s->next to get a chain of server objects, but I can't seem to find a way in C or in Perl to know about the current server. Is there such a thing ? Thanks, -- ___ Robin Berjon <[EMAIL PROTECTED]> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- "What I like about deadlines is the lovely whooshing sound they make as they rush past." --Douglas Adams
Re: detecting ssl
> > > > -Original Message-
> > > > From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, July 10, 2001 10:44 AM
> > > > To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: detecting ssl
> > > >
> > > >
> > > > Not necessarily. I could easily set up any virtualhost on
> > > > port 443 which
> > > > will be accessable by https://nasty.servername/ but will, in
> > > > reality, not
> > > > necessarily be over a secure connection.
> > >
> > > what would negotiate the https protocol then? its not like
> > you can just
> > set
> > > up to listen on 443, make
> > > a an http request, and Apache will serve it - at least not through a
> > browser
> > > or telnet.
> >
> > Of course it will!!!
>
> whoops, I meant an https request - of course you can listen on any port
you
> want for plain http.
Then, you are correct. Of course you could simply just pipe the telnet
session through stunnel, or openssl, or whatever - and work something out
like that. But the point is, then it really IS an HTTP request going over
SSL, so mod_ssl will jump in and set $ENV{HTTPS} anyway, so that really
doesn't say anything.
> [snip]
>
> > Also,
> > if I'd use a
> > simple client that just used https as port 443 without
> > automatically trying
> > to use a secure layer (which is actually proper...), I could even grab
> > https:// from the URI request.
>
> ok, I'm not claiming to be an ssl expert, so how would one do that? if I
do
>
> telnet my.ssl-enabled.server 443
> GET / HTTP/1.0
>
> I get 400 - BAD_REQUEST. something has to negotiate the https layer, no?
Of course. My point is that just because the server's listening on port
443, it doesn't necessarily mean it's using SSL. That's where the danger
is. By checking for $ENV{HTTPS}, you are eliminating that danger by
actually checking whether the individual requests are occuring over a secure
layer, rather than counting on the server and client to do what you would
expect them to - which is the worst mistake that we, as programmers, can
afford to make... :-)
> I've been searching for documentation, but all I can find is the TLS spec,
> which says that TLS is relegated to the scheme of 'https', so pointers to
> something useful would probably be good (for all :)
Umm... If the RFCs aren't helpful, you can try fooling around with (and
reading the man page for) openssl's s_client mode...
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: detecting ssl
> > > > -Original Message-
> > > > From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, July 10, 2001 10:44 AM
> > > > To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: detecting ssl
> > > >
> > > >
> > > > Not necessarily. I could easily set up any virtualhost on
> > > > port 443 which
> > > > will be accessable by https://nasty.servername/ but will, in
> > > > reality, not
> > > > necessarily be over a secure connection.
> > >
> > > what would negotiate the https protocol then? its not like
> > you can just
> > set
> > > up to listen on 443, make
> > > a an http request, and Apache will serve it - at least not through a
> > browser
> > > or telnet.
> >
> > Of course it will!!!
>
> whoops, I meant an https request - of course you can listen on any port
you
> want for plain http.
Then, you are correct. Of course you could simply just pipe the telnet
session through stunnel, or openssl, or whatever - and work something out
like that. But the point is, then it really IS an HTTP request going over
SSL, so mod_ssl will jump in and set $ENV{HTTPS} anyway, so that really
doesn't say anything.
> [snip]
>
> > Also,
> > if I'd use a
> > simple client that just used https as port 443 without
> > automatically trying
> > to use a secure layer (which is actually proper...), I could even grab
> > https:// from the URI request.
>
> ok, I'm not claiming to be an ssl expert, so how would one do that? if I
do
>
> telnet my.ssl-enabled.server 443
> GET / HTTP/1.0
>
> I get 400 - BAD_REQUEST. something has to negotiate the https layer, no?
Of course. My point is that just because the server's listening on port
443, it doesn't necessarily mean it's using SSL. That's where the danger
is. By checking for $ENV{HTTPS}, you are eliminating that danger by
actually checking whether the individual requests are occuring over a secure
layer, rather than counting on the server and client to do what you would
expect them to - which is the worst mistake that we, as programmers, can
afford to make... :-)
> I've been searching for documentation, but all I can find is the TLS spec,
> which says that TLS is relegated to the scheme of 'https', so pointers to
> something useful would probably be good (for all :)
Umm... If the RFCs aren't helpful, you can try fooling around with (and
reading the man page for) openssl's s_client mode...
Issac
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
RE: detecting ssl
> -Original Message-
> From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 10, 2001 1:07 PM
> To: Geoffrey Young
> Cc: [EMAIL PROTECTED]
> Subject: Re: detecting ssl
>
>
> > > -Original Message-
> > > From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, July 10, 2001 10:44 AM
> > > To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: detecting ssl
> > >
> > >
> > > Not necessarily. I could easily set up any virtualhost on
> > > port 443 which
> > > will be accessable by https://nasty.servername/ but will, in
> > > reality, not
> > > necessarily be over a secure connection.
> >
> > what would negotiate the https protocol then? its not like
> you can just
> set
> > up to listen on 443, make
> > a an http request, and Apache will serve it - at least not through a
> browser
> > or telnet.
>
> Of course it will!!!
whoops, I meant an https request - of course you can listen on any port you
want for plain http.
[snip]
> Also,
> if I'd use a
> simple client that just used https as port 443 without
> automatically trying
> to use a secure layer (which is actually proper...), I could even grab
> https:// from the URI request.
ok, I'm not claiming to be an ssl expert, so how would one do that? if I do
telnet my.ssl-enabled.server 443
GET / HTTP/1.0
I get 400 - BAD_REQUEST. something has to negotiate the https layer, no?
I've been searching for documentation, but all I can find is the TLS spec,
which says that TLS is relegated to the scheme of 'https', so pointers to
something useful would probably be good (for all :)
>
> The ONLY safe way, is to use mod_ssl to tell you you're using
> it. Consider
> a comparison: assuming you're using mod_perl by grepping the
> server info for
> mod_perl/x.xx rather than checking $ENV{MOD_PERL}
understood
--Geoff
Re: RFC: Logging used Perl Modules (was Re: API Design Question)
Doug MacEachern <[EMAIL PROTECTED]> wrote:
>On Tue, 3 Jul 2001, James G Smith wrote:
>
>> The current code I have uses %INC, but I wanted to write
>> something like the following:
>>
>> sub use : immediate {
>> # do stuff here if logging
>> return CORE::use(@_);
>> }
>
>you could just override CORE::GLOBAL::require. you don't need to
>override the import, and your version of require will be called at the
>same time as the 'use'.
Thanks! I will see what I can do with that.
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
Re: Accessing server config during parent startup
On Tuesday 10 July 2001 05:42, Doug MacEachern wrote: > On Mon, 9 Jul 2001, Robin Berjon wrote: > > cfg = (axkit_dir_config *) > > ap_get_module_config(s->module_config, &XS_AxKit); > > try s->lookup_defaults instead of s->module_config > > see also: modperl-2.0/src/modules/perl/modperl_pcw.c > where you can see howto access all of the config apache has > parsed. the same logic should work with 1.x, just need to > s/apr_pool_t/pool/g and the like. Thanks Doug, the first option works like a charm :) And I'm far too scared already what with all this finding out about XS and all to apply the second one immediately, but I definitely will once I get a better grasp of these things. Thanks a lot ! -- ___ Robin Berjon <[EMAIL PROTECTED]> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. -- Dirk Gently (Douglas Adams)
Re: detecting ssl
> > -Original Message-
> > From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 10, 2001 10:44 AM
> > To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: detecting ssl
> >
> >
> > Not necessarily. I could easily set up any virtualhost on
> > port 443 which
> > will be accessable by https://nasty.servername/ but will, in
> > reality, not
> > necessarily be over a secure connection.
>
> what would negotiate the https protocol then? its not like you can just
set
> up to listen on 443, make
> a an http request, and Apache will serve it - at least not through a
browser
> or telnet.
Of course it will!!! To prove it, I set up a relatively simple Apache
server with the following httpd.conf file. (I'm not sure how much I can cut
down the httpd.conf file, so there's probably still excess baggage here...)
-
ServerType standalone
ServerRoot "/usr/local/httpd"
PidFile /usr/local/httpd/logs/httpd.pid
ScoreBoardFile /usr/local/httpd/logs/httpd.scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 2
MaxSpareServers 6
StartServers 4
MaxClients 50
MaxRequestsPerChild 200
Port 443
Listen 443
User www
Group www
ServerAdmin [EMAIL PROTECTED]
ServerName some.domain.com
DocumentRoot "/usr/local/httpd/htdocs"
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
AccessFileName .htaccess
DefaultType text/plain
-
Then, I did telnet some.domain.com 443...
-
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2001 15:54:47 GMT
Server: Apache/1.3.20 (Unix) mod_perl/1.25 PHP/4.0.4pl1
Connection: close
Content-Type: text/html
-
Now, if I'd have checked the port, I'd be in trouble. Also, if I'd use a
simple client that just used https as port 443 without automatically trying
to use a secure layer (which is actually proper...), I could even grab
https:// from the URI request.
The ONLY safe way, is to use mod_ssl to tell you you're using it. Consider
a comparison: assuming you're using mod_perl by grepping the server info for
mod_perl/x.xx rather than checking $ENV{MOD_PERL}
Issac
!!!reevaluating part of the module
hi,
What I want is access from module to executed-at-the-moment script namespace
i.e.
the module Utils.pm :
$"abc.asp"::buffer .= 'hello.';
the script xxx.asp :
use Utils;
use vars qw($buffer);
print $buffer
==
How can I do this. Currently I'm doing something like this :
the module Utils.pm :
(export $buffer)
our $buffered = 1;
our $buffer;
eval qq{ $buffer = '' };
sub _print {
if ($buffered) { $buffer .= $_ for @_ }
else { print $_ for @_ };
};
the script :
use Utils;
print $buffer
but this still doen't clear the buffer betwen different invocation of the
script..
tried also :
eval q{ $buffer = '' };
AND
eval { $buffer = '' };
how can I achieve similar effect .. or I'm doing something wrong
PS. It seems to work only if into the script I'm clearing $Utils::buffer at
the begining of the script, but this is exactly what I don't want to do...
want this to be done from outside... code reuse i say :"). It doesn't matter
too much to me where is the $buffer variable in Utils or in the script
name-space, I just don't want to clear it out manualy every time in the
script...
Thanx alot in advance
=
iVAN
[EMAIL PROTECTED]
=
RE: announce: mod_perl-1.25_01
On Tue, 10 Jul 2001, Christian Gilmore wrote: > Hrm. Ok, I'll have to release new versions of my modules that have tests > for mod_perl < 1.26. At what release level do you expect this patch to be > committed? well, i don't want to make any promises like i did for 1.26 :)
Re: PerlInitHandler and PerlSetEnv
On Tue, 10 Jul 2001, Gerald Richter wrote: > The docs says: > > SetEnv directive > Syntax: SetEnv variable value > Context: server config, virtual host > Status: Base > Module: mod_env > Compatibility: SetEnv is only available in Apache 1.1 and later. > Sets an environment variable, which is then passed on to CGI scripts and SSI > pages. Example: > > There is no "directory, .htaccess" in the context and that's like it really > behaves. (unless they changed it in a very recent version and didn't update > the docs, which I don't expect) > > PerlSetEnv is the only chance to have different values in different > directories. i think the docs are out-of-date, seems to work inside location: --- t/conf/httpd.conf~ Mon Jul 9 20:23:10 2001 +++ t/conf/httpd.conf Tue Jul 10 08:35:03 2001 @@ -160,6 +160,7 @@ +SetEnv mod_env location PerlSetVar StatusOptionsAll On SetHandler perl-script PerlHandler +Apache::Status % GET 'http://localhost:8529/perl/perl-status?env' | grep mod_env mod_env = location
Re: Apache::SimpleTemplate (don't do it!)
On Mon, Jul 09, 2001 at 02:07:21PM -0400, Perrin Harkins took time to write: > > I think that CGI::FastTemplate does all of that. > > Please have a look at it, and see if everything you need is not > > already in it. > > It's a good module for CGI, since it doesn't rely on caching/compiling > techniques, just simple regex stuff. It will use a lot less RAM than tools > that compile in-line perl, because it doesn't eval anything or cache > anything. The only real downside of this module is that coding repeated > sections (loops) can't be done in-line, i.e. you have to use multiple files. > That's a bit of a pain. Yes and no. It is a simple template thing. The original poster wanted : it's either code or it's not. no added tags, etc. In CGI::FastTemplate there is no embedded code, no added tags, so it suits that need perfectly. If you want more advanced stuff (loops, code, etc...) then probably Mason, AxKit or things like that will be more of your taste. Personnally, since 2 years, CGI::FastTemplate was always enough for me. Needs are different. CGI::FastTemplate is very good for very basic needs (that is no HTML code in mod_perl handlers, but in separate files). For more advanced needs there are other solutions. -- Patrick. ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.'' PGP signature
RE: PerlInitHandler and PerlSetEnv
Doug, Thanks for the quick turn around. The patch works great. -MikeB. -Original Message- From: Doug MacEachern [mailto:[EMAIL PROTECTED]] this patch should fix the problem. you should also be able to s/PerlSetEnv/SetEnv/g, unless Embperl needs these variables before the fixup phase.
RE: detecting ssl
> -Original Message-
> From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 10, 2001 10:44 AM
> To: Geoffrey Young; 'João Pedro Gonçalves'; brian moseley
> Cc: [EMAIL PROTECTED]
> Subject: Re: detecting ssl
>
>
> Not necessarily. I could easily set up any virtualhost on
> port 443 which
> will be accessable by https://nasty.servername/ but will, in
> reality, not
> necessarily be over a secure connection.
what would negotiate the https protocol then? its not like you can just set
up to listen on 443, make
a an http request, and Apache will serve it - at least not through a browser
or telnet.
but maybe there are ways to spoof the SSL layer?
> $ENV{HTTPS}, on the
> other hand, is
> set by mod_ssl, and is therefore a better sign to know that
> the connection
> is really secure.
that's good to know... thanks
--Geoff
new CGI.pm and multipart/form-data
Had the same problem two days ago, solved it by copying old CGI.pm (luckily we have few computers running linux). Does Cpan have old module versions ? I believe so ...
RE: detecting ssl
Looking at the port number still doesn't ensure that the request is a SSL
request. I believe the mention to looking at $ENV{HTTPS} is the best couse
as that is set when the connection is a SSL connection and not just a
connection to port 443.
--Joe Breeden
--
Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com)
> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 10, 2001 8:50 AM
> To: brian moseley
> Cc: [EMAIL PROTECTED]
> Subject: Re: detecting ssl
>
>
> > no need to do a lookup or rely on PerlSetupEnv On I
> wouldn't think...
> >
> > my $ssl = Apache::URI->parse($r)->scheme =~ m/^https/;
>
> Or maybe just look at the port # of the request.
> - Perrin
>
[Solved] ASP.pm and multipart/form .. error
hi, I moved to CGI.pm 2.74 and everything is OK now :") So be aware that u may have problems with the following config : RedHat 7.1 + Apache 1.3.20/mod_perl 1.25, ASP.pm, CGI ver 3.x CGI 3.01 even gives error on /compilation test. CGI 3.02 doesn't give this error HtH = iVAN [EMAIL PROTECTED] =
RE: announce: mod_perl-1.25_01
Hrm. Ok, I'll have to release new versions of my modules that have tests for mod_perl < 1.26. At what release level do you expect this patch to be committed? Regards, Christian > -Original Message- > From: Doug MacEachern [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 09, 2001 10:37 PM > To: Christian Gilmore > Cc: 'Modperl Mailing List (E-mail)' > Subject: Re: announce: mod_perl-1.25_01 > > > On Mon, 9 Jul 2001, Christian Gilmore wrote: > > > Doug, > > > > I didn't see in the announcement that the below fix is included in > > 1.25_01. Can you please confirm? > > the patch has not been committed and will probably wait until after > 1.26. i'm concerned that the current patch might introduce bugs > elsewhere, its a thorny problem to solve and i don't want to > delay 1.26 > any longer. > >
help about ap_pool in Perl
Hi I need to use the ap_pool structure. In my Apache Module writing book is explained how to use it in C but nothing is said about using it in Perl. How does it work ? How may I use it in Perl? Many Thanks -- Alberto Canzi OpenFor s.r.l. e-mail: [EMAIL PROTECTED]
Re: detecting ssl
> no need to do a lookup or rely on PerlSetupEnv On I wouldn't think... > > my $ssl = Apache::URI->parse($r)->scheme =~ m/^https/; Or maybe just look at the port # of the request. - Perrin
Re: detecting ssl
Not necessarily. I could easily set up any virtualhost on port 443 which
will be accessable by https://nasty.servername/ but will, in reality, not
necessarily be over a secure connection. $ENV{HTTPS}, on the other hand, is
set by mod_ssl, and is therefore a better sign to know that the connection
is really secure.
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
- Original Message -
From: "Geoffrey Young" <[EMAIL PROTECTED]>
To: "'João Pedro Gonçalves'" <[EMAIL PROTECTED]>; "brian moseley"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 14:33
Subject: RE: detecting ssl
>
>
> > -Original Message-
> > From: João Pedro Gonçalves [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 10, 2001 9:08 AM
> > To: brian moseley
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: detecting ssl
> >
> >
> > This approach should be ok:
> >
> > my $s = $r->lookup_uri($r->uri);
> > my $ssl = $s->subprocess_env('HTTPS');
> >
> > I looked at this a while back and this is usually set internally
> > in apache by the ssl implementation.
>
> no need to do a lookup or rely on PerlSetupEnv On I wouldn't think...
>
> my $ssl = Apache::URI->parse($r)->scheme =~ m/^https/;
>
> ?
>
> --Geoff
>
Re: [CGI.pm] ASP.pm and multipart/form .. error
hi again,
I've made some tests and debuging, the problem seems to be in CGI module...
first of all in eg/file_upload.asp this :
print $q->start_multipart_form();
returns this :
do U see no POST (the interesting thing is that $r->method returns GET in
this case i didn't knowed that :") ).. even when I make it manualy and put
debuging code into $Request object multipart handling
if($@) {
$self->{asp}->Error("can't use file upload without CGI.pm:
$@");
} else {
my %form;
my $q = $self->{cgi} = new CGI;
$self->{debug} = '-->'.$q->param('xxx');# <=
there is one more text field in the form named 'xxx'
for(my @names = $q->param) {
my @params = $q->param($_);
..
I get nothing into $$Request{debug}
SO CAN SOMEONE TELL ME FROM WHERE I CAN GET CGI with LOWER VESRION THAN 3.02
:"(
Thanx alot
=
iVAN
[EMAIL PROTECTED]
=
> ivan wrote:
> >
> > hi there ,
> >
> > I encoutred a problem with ASP.pm (ver.2.17) and multipart form what is
> > happening is that when I try to use "file" fields I get something like
this
> > into the log
> >
> > [Mon Jul 9 23:20:22 2001] [error] [client 192.168.0.5] Invalid method
in
> > request -7d11b8668d0668
> > [Mon Jul 9 23:20:41 2001] [error] [client 192.168.0.5] Invalid method
in
> > request -7d13c1268d0668
> > [Mon Jul 9 23:21:41 2001] [error] [client 192.168.0.2] Invalid method
in
> > request -7d17811a20
> >
> > if the form is normal (w/o enctype="multipart/form-data" ) I'm getting
> > normally data into $Request.. nothing is crashing just I'm getting
nothing
> > into $Request collection...
> >
>
> Can you get the ./site/eg/file_upload.asp example working from
> the distribution? If so, see what's different about your script.
> I believe I'm running the same Apache + modperl now too, and I
> have never seen the problem you report, Apache 1.3.20, mod_perl 1.25
>
> BTW, from the error, it doesn't look like it has to do with Apache::ASP.
> Maybe someone from the modperl list will give you some better info
> specific to modperl.
>
> -- Josh
help about ap_pool in Perl
Hi I need to use the ap_pool structure. In my Apache Module writing book is explained how to use it in C but nothing is said about using it in Perl. How does it work ? How may I use it in Perl? Many Thanks -- Alberto Canzi OpenFor s.r.l. e-mail: [EMAIL PROTECTED]
Re: Tutorials Need To Learn More
On Fri, 6 Jul 2001, Purcell, Scott wrote: > Hello, > I am working with mod_perl and apache on NT (No ripping please ... it is a > political issue here at my work.). > Anyway, I have been trying to learn more about taking advantage of handlers, > etc. I purchased the book "Writing Apache Modules with Perl and C", but it > is NOT NT friendly. Most of the examples DO NOT work on my NT mod_perl. > > Anyway, I figure there has to be more resources than just that book. Does > anyone know of any? I am looking for examples and techniques to get me > rolling. http://take23.org/articles/ -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
RE: detecting ssl
> -Original Message-
> From: João Pedro Gonçalves [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 10, 2001 9:08 AM
> To: brian moseley
> Cc: [EMAIL PROTECTED]
> Subject: Re: detecting ssl
>
>
> This approach should be ok:
>
> my $s = $r->lookup_uri($r->uri);
> my $ssl = $s->subprocess_env('HTTPS');
>
> I looked at this a while back and this is usually set internally
> in apache by the ssl implementation.
no need to do a lookup or rely on PerlSetupEnv On I wouldn't think...
my $ssl = Apache::URI->parse($r)->scheme =~ m/^https/;
?
--Geoff
Re: detecting ssl
This approach should be ok:
my $s = $r->lookup_uri($r->uri);
my $ssl = $s->subprocess_env('HTTPS');
I looked at this a while back and this is usually set internally
in apache by the ssl implementation.
João Pedro
brian moseley wrote:
>
> warning: these may be silly questions. but i've looked
> through the guide and not found the answers, so hopefully
> they're not that silly.
>
> how can i test in a content handler if the request was
> received over an ssl connection? do i have to look for an
> environment variable? is there a test that works with all
> the various ssl modules? is there a standard "ssl
> interface"? if so, where is it documented?
>
> thanks!
detecting ssl
warning: these may be silly questions. but i've looked through the guide and not found the answers, so hopefully they're not that silly. how can i test in a content handler if the request was received over an ssl connection? do i have to look for an environment variable? is there a test that works with all the various ssl modules? is there a standard "ssl interface"? if so, where is it documented? thanks!
Re: announce: mod_perl-1.25_01
On Fri, 6 Jul 2001, Doug MacEachern wrote: > adjust perl_clear_symtab() to deal properly bleedperl's version of > cv_undef() (which broke modules with directive handlers) > thanks to Geoffrey Young for the spot FWIW, perl_clear_symtab is the only part of config directives now that cause segfaults for AxKit users. Without that line, we're totally clear of complaints (removed for AxKit 1.4_80), apart from the old expat segfaults. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Install problems with Apache 1.3.12 - Raven SSL 1.4.1 - mod_perl 1.25 and perl 5.6.x
Hello, My apache segfaults when I start it in SSL mode and a page is accessed. If it is started in standard mode, it runs fine. I've been able to create a stable apache using apache 1.3.12-Raven 1.4.1-mod_perl 1.24 and perl 5.005_3. I think the problem is more in the perl version than the mod_perl version. I've tried it with 5.6.1 with no success; 5.6.0 scared me so I can't quite remember if I tried it several months back. I'm sure the problem is in how I am compiling it, with the most likely cause being how I upgraded to perl 5.6.1 from from 5.6.0 on my RH 7.0 system. I did it using CPAN, but it didn't seem to put the binary in the right place for 5.6.1 to be recognized. So, I just copied the binary to /usr/bin/perl where RH had put it. Then, I built apache/mod_perl/Raven and ran into the above problems. The perl has run fine since doing the upgrades. mod_perl & Mason run fine as long as I keep it out of SSL mode. Could I have upgraded perl incorrectly? It is possible that I setup raven before upgrading to perl 5.6.1 -- could this be causing the problem? If I have upgraded perl incorrecly, how should I do it? Any clues would be very helpful! Take care, Kurt Hansen [EMAIL PROTECTED] P.S. Anyone else find the non-standard places RH puts things very annoying? Seems kind of Microsoftian (rhymes with Faustian...) Or, maybe my brain is just too small to do the conversion from the documentation to RH's file system.
