date:20030715

Philippe M. Chiasson wrote:
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:

This fixed the bug for me.


Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
-1, this is a wrong solution. print ; should flush just like it did in 
mod_perl 1.0 if $| == 1; Consider this script:

print Content-type: text/plain\n\n;
local $| = 0;
print start\n\n;
local $| = 1;
print ;
sleep 5;
local $| = 0;
print end\n;
print , must immediately flush the buffered data, since $| has changed from 
0 to 1.


One thing that could help is if someone could take the time to write a
test for this bug.
Unfortunately I don't seem to be able to reproduce the problem, so I can't 
debug the problem. It could be a bug on the mod_deflate's behalf as well. 
Philippe, were you able to reproduce the problem with Bill's setup? I was 
writing a test, but couldn't get it to fail... may be because i was using 
2.0.47. Bill, do you have the problem with the latest apache version?

Also Bill, why do you have this setup:

Location /perl
  AddOutputFilterByType DEFLATE text/*
  SetOutputFilter DEFLATE
/Location
why adding it twice? You need only the latter inside Location, or 
alternatively only the former outside Location if you want it to be set 
globally:
http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Is statically-compiled mod_perl better?


It seems that at present it is not possible to build mod_perl 2.0
statically. It can only be built dynamically and loaded using
LoadModule in httpd.conf. This seems strange if the preferred method of
building is static.
What was right for 1.0 doesn't necessarily right for 2.0. mod_perl 2.0 DSO 
seems to be just fine, besides having linking problems on certain OSes (like 
mac) which will be resolved as soon as an expert of the relevant OS will 
provide us help.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache config problem .. please help


Anyway, all this started from an attempt to access env. vars from legacy 
scripts running under registry. What is the easiest way to get env. var 
access without the accompanying performance penalty that mod_perl 
documentation talks about?
If you need to have your scripts run unmodified, have PerlSetupEnv Off in all 
sections that you don't need to access the CGI env vars, and have it On only 
in those Locations that run legacy scripts.
http://perl.apache.org/search/swish.cgi?query=PerlSetupEnvsbm=SecEsubmit=search

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache::Registry - String Compaction == Less RAM?

Perrin Harkins wrote:
On Mon, 2003-07-07 at 11:50, Nigel Hamilton wrote:

I thought I could save some RAM by stripping out comments and
whitespace before the eval step - so I quickly wrote a Registry-like
handler that strips comments.


Those don't take up any space in the actual compiled opcodes.  The only
space you could save is in the string that the file is initially loaded
into and the $eval string that gets built up to pass to eval().
[...]

I'd just like to add an example which shows you what exactly perl sees when it 
compiles your code:

perl -MO=Deparse -le '\
print \
this is a string \
# hmm, some comment \
. another string \
# bummer, i should end the line now \
;'
prints:

BEGIN { $/ = \n; $\ = \n; }
print 'this is a stringanother string';
-e syntax OK
Also see:

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache::Registry - String Compaction == Less RAM?

[sent it out too early]

Stas Bekman wrote:
Also see:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlResponseHandler

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [MP2 - BUG ?] Issue handing Apache config. error messages

Issac Goldstand wrote:
Right.  Could you possibly clarify the difference between  SetHandler
perl-script and SetHandler modperl?  I'm still not sure I've got the
straight of it yet...
You must be kidding ;) Have you read the sections at the URL posted below?

Stas Bekman wrote:

Sreeji K Das wrote:
[...]
You need to use 'SetHandler perl-script' for that, see:
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_


__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: mod-perl - read

2003-07-15 Thread Thomas Klausner

Hi!

On Mon, Jul 14, 2003 at 04:46:37PM -0500, Siva Yendapalli wrote:
 I am totally a newbie to mod_perl. I could able to get the content length
 using $r-headers_in(Content-Length). but I don't see anything in the $buf
 when I call the function $r-read($buf,$r-headers_in(Content-Length)). I

Is there any reason you want to parse the request yourself? You can use
Apache::Request to access the POST/GET data

 am sure I am doing some thing wrong with the configuration or with mod_perl 
 program. Please can some body give me an example and what I should do with
 the configuration to load the program. 

see perldoc Apache::Request

The mod_perl Website http://perl.apache.org also has a huge amount of
information (including pointers to the various mod_perl books).

-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}

Re: untainting PATH in mod_perl

Dominique Quatravaux wrote:
 Sorry, getting out of good ideas.. 


  Surprise, surprise: I found out that my code does not work under
mod_perl 1.23 either! And I found the real solution: one has to add
  PerlSetupEnv Off

to the Apache configuration file. Now the untainting mumbo-jumbo in
perl section works.
  Warning: this has the consequence of breaking the part of the CGI
environment emulation that deals with environment (e.g. instead of
$ENV{HTTP_USER_AGENT}, you now have to check
Apache-request()-subprocess_env(HTTP_USER_AGENT)). Glancing at its
source code, I don't think CGI.pm will survive that...
  BTW, I finally got around to reading mod_perl's source, and it
is now clear to me that the environment, when being copied from
-subprocess_env() into %ENV, gets tainted (around line 704 in
src/modules/perl/mod_perl.c). The whole %ENV gets tainted, not just
the HTTP_USER_AGENT and such from the CGI context, so PATH is tainted
as well. This explains our now common problem - and also guarantees
that there is no easy way out of it if you use CGI.pm yourself :-(.
You need to untaint the variables before you use them. Since they get reset on 
every request, you need to untaint them inside your script/handler's run time, 
not the BEGIN block...:
http://perl.apache.org/docs/1.0/guide/porting.html#BEGIN_blocks

it should work just fine with mp1 and mp2.

Relying on 'PerlSetupEnv Off' is not a very good idea, since if you want to 
release your code for others to use, they may not be able to turn it off, 
since it'll break their CGI-legacy code as you have observed.

FWIW, I use the following code when I need to use ``|qx:

local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: mod_perl 1.0 and 2.0

Sreeji K Das wrote:
[...]
I'd also think mod_perl 1.x series may be
discontinued after a while, as 2.x gets to be used
widely (however, it may be a while).
The term discontinued doesn't quite apply to Open Source software. A few 
years from now when the majority will move to mod_perl 2.0, mod_perl 1.0 might 
be not worked on actively, but being an open source the project it will be 
maintained as long as someone will volunteer to do that.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: compile issue: conflicting types for getline

Stewart, Eric wrote:
	Apologies for duplication - I've discovered some unexpected behavior with the pasting into a W2K session of VPC 6 on Mac 10.2.6 - and then got a little clicky and clicked on the wrong thing. :(

On RedHat Linux 9.0, with Apache 1.3.27, PHP 4.3.2, and mod_perl 1.28, I'm getting a compile error.  These, near as I know, are the latest stable versions of everything - which is why I suspect I'm running into this problem:

make[2]: Entering directory `/usr/local/src/apache_1.3.27/src/support'
gcc -c  -I../os/unix -I../include   -DLINUX=22 -D_REENTRANT -D_GNU_SOURCE 
-DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm  
-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE  `../apaci` htpasswd.c
htpasswd.c:145: conflicting types for `getline'
/usr/include/stdio.h:473: previous declaration of `getline'
make[2]: *** [htpasswd.o] Error 1
make[2]: Leaving directory `/usr/local/src/apache_1.3.27/src/support'
make[1]: *** [build-support] Error 1
make[1]: Leaving directory `/usr/local/src/apache_1.3.27'
make: *** [build] Error 2
I've seen posts that point the finger at mod_perl.  This may be the case as I've 
managed to compile another Apache server without mod_perl on a different system (RH 9 
with PHP).  However, I'm thinking it's more along the lines of a compiler (IOW, 
RedHat's use of gcc 3.2.2) issue.
What I could really use is a solution to get past this point - I'd rather like to avoid 
downgrading either my OS or compiler.  I also kind of need the support tools 
including htpasswd, so skipping them in the compile is highly undesired.  ./configure options or 
even Makefile modifications are preferred.  Code patches are acceptable, even to some extent 
expected, but I'm a lazy systems admin, not a programmer ...
Of course, any assistance at all (as repeated and varied searches on groups.google 
and www.google only verify the problem's existence and have yet to provide a solution) 
is welcome and appreciated.
Not quite a mod_perl problem per se. It's probably perl that includes 
/usr/include/stdio.h. However htpasswd.c's definition is static, so you can 
workaround it by simply doing:

perl -pi -e 's|getline|my_getline|' src/support/*.c

Of course this shouldn't have been a problem in first place, because this 
function is status.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Undocumented behaviour in Apache-print()?

Steve Hay wrote:
Hi,

I've just spent quite a while tracking down a problem with a web page 
generated by a mod_perl program in which 8-bit ISO-8859-1 characters 
were not being shown properly.  The software runs via Apache::Registry, 
and works fine under mod_cgi.

It turns out that the problem is due to a difference in behaviour 
between Perl's built-in print() function in Perl 5.8.0+ and the 
Apache-print() method that mod_perl overrides it with.  I've consulted 
the documentation on the mod_perl website, and could find no mention of 
the difference.  If my conclusions below are correct then this 
information may well be worth adding.
[the rest of the very detailed analysis has been snipped]

5.8.0 is a pretty new perl version, which provides the new functionality, and 
it seems that hardly anybody has been using the UTF stuff with mod_perl. So I 
suppose you are the first one to hit the problem. Certainly we need to update 
mod_perl to handle this correctly. Would you be interested to try to make 
Apache-print() do the right thing? If not, we should log it in the STATUS 
file and hopefully someone will have the time and inclination to solve it.

In any case a simple test that reproduces the problem will be needed.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Dynamically banning hosts

Mustafa Tan wrote:
Is it possible to dynamically ban IP addresses using
mod_perl. Like even the first connection from the
specified ip will be rejected. I know that you can do
this using httpd.conf but I am wondering how to do the
same dynamically while Apache is running.
Also how can I cope with denial of service attacks? I
know there is no general solution to this, but is
there a particular technique to ease the problem. The
environment is one host that serves small number of
people with a very limited bandwidth.
in mod_perl 2.0 you can do it even better:
http://perl.apache.org/docs/2.0/user/handlers/protocols.html#PerlPreConnectionHandler
or during the normal mp1-like handler:
http://perl.apache.org/docs/2.0/user/handlers/http.html#toc_PerlAccessHandler


__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [mp2] Apache::DBI

Beau E. Cox wrote:
Hi -

I am running Apache 2.0.47/mod_perl 1.99-dev-10-cvs
on SuSE Linux 8.2. I am trying to install and use
Apache::DBI.
[...]
2) The documentation says to configure mod_perl with:

  perl Makefile.PL PERL_CHILD_INIT=1 PERL_AUTHEN=1 PERL_AUTHZ=1 
   PERL_CLEANUP=1 PERL_STACKED_HANDLERS=1

   These are mod_perl 1 parameters. I could not find any
   corresponding mod_perl 2 parameters.
That documentation is talking about mod_perl 1.0, mod_perl 2.0 doesn't need 
any of these compile options. which URL you are talking about? Perhaps it 
should be fixed to say that you need these options only if you use mp1.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: module ported and doc addition...

Shannon Eric Peevey wrote:
[...]
Also, you don't realy have to do that. The old ala mp1 style works 
just fine.

use Apache::Const qw(OK DECLINED)

sub handler {

   return OK;
} 


Well...  I must have been smoking crack, 'cause I seem to remember a 
simple:

return  MP2 ? Apache::OK : OK

throwing an error, hence, the change to:

MP2 ? Apache::OK : Apache::Constants::OK

Now that I test it, though, there doesn't seem to be a problem...  :P
May be you haven't been importing the constant. These two aren't the same:

use Apache::Const qw(OK DECLINED);
use Apache::Const -compile = qw(OK DECLINED);
the latter only compiles the constants, the former compiles and imports it.

[...]

Thanks.  I have received that permission from Mr. Horner since I have 
written this email.  I have contacted the [EMAIL PROTECTED] gang, but 
they haven't responded yet.  (No problems, as I am about to start on 
Apache-AuthNTLM.)  I will upload another version to CPAN when they give 
me authorization. :)

Also, I have ported:

Apache-AuthenPasswd
Apache-AuthzPasswd
I've updated the online list.

with notices as to the limitations of these modules.  (I inherited these 
with the AuthenNIS mods...  Haven't had a chance to port those yet, 
though.)  They have been uploaded and indexed on CPAN.
Since you now have the perms, you no longer need to get the blessing from the 
modules list. Simply go ahead and upload your module. First go to the PAUSE 
interface and check that you actually co-own the modules in question.

Also need to get excited about getting the authperlldap mod done as 
well... :)
;)

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Memoize.pm and mod_perl

[EMAIL PROTECTED] wrote:
Has anyone used the Memoize module extensively in a mod_perl environment?
I am thinking of using it to cache queries from the database, particularly
for lookups (somthing like $obj-get_name_from_id()).
In many cases the data is static so I don't mind is staying over from one
request to the next but I wanted to primarily use to limit the number of
queries per http request.  To keep the cache from growing (the website
receives 20 hit/min on average w/ 20,000 users) I wanted to either
implement a LRU/Expiration cache.  The other alternative I was considering
was to use a cleanup handler after every request.
I would like to know any experiences/thoughts anyone has had of using
Memoize in a mod_perl environment.
Memoize should work just fine under mod_perl. If you need to reset the cache 
between requests you should call its flush_cache() function. refer to its 
manpage for more info.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [mod_perl] Re: Content compression FAQ

Ross Matt-QMR000 wrote:
I like to be removed from this list but the un-scribe does not work for me.
the problem is the mail address that I used way back when has been aliases.
the list's help email explains how to unsubscribe from a different address, 
post to [EMAIL PROTECTED] for the details. If everything else fails 
please contact [EMAIL PROTECTED]

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: AuthenNTLM - Help

Francisco de Assis Tristão wrote:
Frank,
please, i am trying to configure AuthenNTLM on a solaris 2.8 (SPARC)
machine. But i did not find any sample about how to configure
httpd.conf. May you help me? I had compiled apache 2 version 2.0.46 with
ssl suport (i am configuring it with mod_jk and Tomcat too). Do i need
to have mod_perl installed?
You certainly need to have mod_perl installed. This and other questions are 
answered at http://perl.apache.org/.

However I'm not sure whether this module has been ported to mod_perl 2.0. 
Therefore you probably need to either port it, or use mod_perl 1.0, in case it 
wasn't ported yet.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: mod-perl - read

Siva Yendapalli wrote:
I am totally a newbie to mod_perl. I could able to get the content 
length using $r-headers_in(Content-Length). but I don't see anything 
in the $buf when I call the function 
$r-read($buf,$r-headers_in(Content-Length)). I am sure I am doing 
some thing wrong with the configuration or with mod_perl program. Please 
can some body give me an example and what I should do with the 
configuration to load the program.
You provide to little context to be able to answer your question. Which 
mod_perl are you using 1.0 or 2.0? Can you post a short code snippet that you 
have a problem with? Which phase are you calling the handler from? Or is it a 
registry script?

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Bareword Apache::OK not allowed, Apache::PerlSection

Alexander Newald wrote:
Hello,

I have installed mod_perl2

(http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz,
mod_perl-1.99_09)
with

cd mod_perl-1.99_09
perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache2
and added

LoadModule perl_module modules/mod_perl.so
Perl 
$ServerName = `hostname`;
/Perl
to my httpd.conf

When I try to start the server I get

[Mon Jul 14 14:46:25 2003] [error] failed to resolve handler
`Apache::PerlSection'
Syntax error on line 321 of /etc/httpd/httpd.conf:
Bareword Apache::OK not allowed while strict subs in use at
/usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/PerlSection.pm line 47.
BEGIN not safe after errors--compilation aborted at
/usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/PerlSection.pm line 58.
Compilation failed in require at (eval 2) line 3.
It doesn't matter what I put between Perl  /Perl

Any hints?
works fine for me, may be you need to add:

PerlModule Apache2

before your first Perl section?

Also I'd suggest to always run your mod_perl server with:

PerlSwitches -wT

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

[mp2] Apache::Cookie

2003-07-15 Thread Swen Schillig

Are there any plans to have Apache::Cookie or does
mp2 code always has to use CGI if there are cookies needed ?

Swen

Re: [RFC] web-messaging application for mod_perl

Adi Fairbank wrote:
On, or in the near vicinity of Mon, 14 Jul 2003 18:49:58 +0300
Stas Bekman [EMAIL PROTECTED] has thus written:

Probably the best bet is to give it some cool unique name, like 
Apache::AdiChat and then you are all set, since you are not going to take over
[...]
What's wrong with WebMessaging ?  Do you foresee that interfering with some
future software in the Apache:: namespace, or is it just too generic?  I thought
it was a good name since it accurately describes what it is: not webmail, not
instant messaging, but web messaging.  (basically, it's like those message boxes
you get on a stock trading website when you login to your account)
James has gone into a detailed reply why this could be a bad idea. I'd just 
add that it's very hard to choose a good name for a module. And it seems that 
unique k001 names never have such problems.

Perhaps you can have a unique name for your application and in the future you 
will extract a framework from it, making your app use it and allowing other 
apps to do the same. So with time you will see whether Apache::WebMessaging is 
a good name and whether it fits well into the scope of what it's supposed to do.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Virtual Host Logging Perl Script

Jez Hancock wrote:
Hi,

I've just written a short perl script to perform logging for our virtual
hosts.  The code has plenty of comments so I'll paste it below.
My question is: would it be possible to use mod_perl in some way to
perform the function of the script?  In testing the speed of the script
seems reasonable enough, is there a better way to do what I'm doing
below?
Take a look at:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler
a similar code will work for mp1 if you don't use 2.0.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: untainting PATH in mod_perl

2003-07-15 Thread Peter B. Ensch

On Tue, Jul 15, 2003 at 12:19:14PM +0300, Stas Bekman wrote:
 Dominique Quatravaux wrote:
  Sorry, getting out of good ideas.. 
 
 
   Surprise, surprise: I found out that my code does not work under
 mod_perl 1.23 either! And I found the real solution: one has to add
 
   PerlSetupEnv Off
 
 to the Apache configuration file. Now the untainting mumbo-jumbo in
 perl section works.
 
   Warning: this has the consequence of breaking the part of the CGI
 environment emulation that deals with environment (e.g. instead of
 $ENV{HTTP_USER_AGENT}, you now have to check
 Apache-request()-subprocess_env(HTTP_USER_AGENT)). Glancing at its
 source code, I don't think CGI.pm will survive that...
 
   BTW, I finally got around to reading mod_perl's source, and it
 is now clear to me that the environment, when being copied from
 -subprocess_env() into %ENV, gets tainted (around line 704 in
 src/modules/perl/mod_perl.c). The whole %ENV gets tainted, not just
 the HTTP_USER_AGENT and such from the CGI context, so PATH is tainted
 as well. This explains our now common problem - and also guarantees
 that there is no easy way out of it if you use CGI.pm yourself :-(.
 
 You need to untaint the variables before you use them. Since they get reset 
 on every request, you need to untaint them inside your script/handler's run 
 time, not the BEGIN block...:
 http://perl.apache.org/docs/1.0/guide/porting.html#BEGIN_blocks
 
 it should work just fine with mp1 and mp2.
 
 Relying on 'PerlSetupEnv Off' is not a very good idea, since if you want to 
 release your code for others to use, they may not be able to turn it off, 
 since it'll break their CGI-legacy code as you have observed.
 
 FWIW, I use the following code when I need to use ``|qx:
 
 local $ENV{PATH} = /bin:/usr/bin;
 local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
 
 

But this code must be used in each scope where you intend to use 
backticks, a system call Etc. Is there no way to untaint your
PATH environment one time for the script or handler?

P

-- 
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter B. Ensch ([EMAIL PROTECTED])   
   
Linux 2.4.20-4GB 5:47am Up 2 days 18:47
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^

Re: [MP2 - BUG ?] Issue handing Apache config. error messages

2003-07-15 Thread Issac Goldstand

- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Issac Goldstand [EMAIL PROTECTED]

 Issac Goldstand wrote:
  Looking at it now, I tend to agree...  I just have a vague recollection
of
  my first mod_perl 2 handler (Written only 2 weeks ago, though I dabbled
with
  the C API 9 months ago, already) and reading it and playing with
httpd.conf
  and overall being very confused.

 I've just committed the examples, hopefully they will appear online soon.

  I'd consider having 2 guides written - a porting guide - yours is nice,
but
  more as reference than as tutorial - and the second for newbies
(Starting
  with mor_perl 2)...  I'm toying with the idea of starting the porting
  tutorial, but I want to make sure it's written well for clueless people
  (which I probably still at least half count as :-)) and with accurate
  content.

 porting or starting? We already have a porting guide:
 http://perl.apache.org/docs/2.0/user/porting/porting.html

 a porting reference:
 http://perl.apache.org/docs/2.0/user/porting/compat.html

Right - I read it, and it's reference.  It's not a good guide.  A guide
should start with the basics.  The mp_1 guide is one of the most beautiful
pieces of electronic documentation in existance!  It should be a book (I
know: practical mod_perl)  Seriously though - the guide is what personally
turned me on to mod_perl, but the above two documents make me shiver and
stay the hell away from mp_2.  What's needed is a good friendly piece of
documentation to get people moving... to mp_2

 and even getting started:
 http://perl.apache.org/docs/2.0/user/intro/start_fast.html

Will look at it shortly - Let's not bite off more than we can chew in one
mouthful.

 I'd suggest to improve these docs where approapriate and start a new doc
only
 if it really doesn't fit into the existing docs.

I'm just not sure if it *does* fit...

  Issac

Re: Undocumented behaviour in Apache-print()?

2003-07-15 Thread Steve Hay

Hi Stas,

Stas Bekman wrote:

Steve Hay wrote:

Hi,

I've just spent quite a while tracking down a problem with a web page 
generated by a mod_perl program in which 8-bit ISO-8859-1 characters 
were not being shown properly.  The software runs via 
Apache::Registry, and works fine under mod_cgi.

It turns out that the problem is due to a difference in behaviour 
between Perl's built-in print() function in Perl 5.8.0+ and the 
Apache-print() method that mod_perl overrides it with.  I've 
consulted the documentation on the mod_perl website, and could find 
no mention of the difference.  If my conclusions below are correct 
then this information may well be worth adding.


[the rest of the very detailed analysis has been snipped]

5.8.0 is a pretty new perl version, which provides the new 
functionality, and it seems that hardly anybody has been using the UTF 
stuff with mod_perl.
5.8.0 is actually a couple of days short of being one year old (happy 
birthday!), which is increasingly not that new any more.  5.8.1 should 
be out soon too.

As for hardly anybody using UTF8 stuff with mod_perl... I didn't think 
that I was until I realised that most XML parsers (certainly the two 
that I most uses -- XML::LibXML and XML::DOM) return all their data in 
Perl's internal UTF-8 format!  Then the penny dropped that I was 
actually using it rather a lot :-)

So I suppose you are the first one to hit the problem. Certainly we 
need to update mod_perl to handle this correctly. Would you be 
interested to try to make Apache-print() do the right thing?
Hmm.  We really need somebody who understands the internals of Perl and 
mod_perl better than me, but here's a first stab at it:

The Perl source code contains a pp_print() function in pp_hot.c which 
I presume is basically CORE::print().  It makes use of a do_print() 
function.  I think that function comes from doio.c, although it's 
actually called Perl_do_print() there.  That function does some stuff 
with the UTF-8 flag, which I guess is the sort of thing that we're 
after.  Here's a chunk of Perl_do_print() from Perl 5.8.0:

   if (PerlIO_isutf8(fp)) {
   if (!SvUTF8(sv))
   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
   }
   else if (DO_UTF8(sv)) {
   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
ckWARN_d(WARN_UTF8))
   {
   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
   }
   }
I think what this does is look to see if the fp (a PerlIO *) has the 
:utf8 encoding layer.  If so, then it upgrades the sv to UTF8 (which 
is always possible).  If not, then it looks to see if the bytes pragma 
is enabled.  If not, then it downgrades the sv from UTF8 (which is not 
always possible -- if that fails and the UTF8 warnings category is 
enabled then it outputs the good ol' Wide character in print warning).

I have attempted to shoe-horn this into mod_perl's print() method (in 
src/modules/perl/Apache.xs).  Here's the diff against mod_perl 1.28:  
[Unfortunately, I've had to comment-out the first part of that if 
block, because I got an unresolved external symbol error relating to the 
PerlIO_isutf8() function otherwise (which may be because that function 
isn't documented in the perlapio manpage).]

--- Apache.xs.orig2003-06-06 12:31:10.0 +0100
+++ Apache.xs2003-07-15 12:20:42.0 +0100
@@ -1119,12 +1119,25 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+/*PerlIO *fp = PerlIO_stdout();*/
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+/*if (PerlIO_isutf8(fp)) {
+if (!SvUTF8(sv))
+sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+}
+else*/ if (DO_UTF8(sv)) {
+if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ ckWARN_d(WARN_UTF8))
+{
+Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+}
+}
+
PUSHMARK(sp);
XPUSHs(rp);
XPUSHs(sv);
Besides the problem with PerlIO_isutf8(), there are other problems that 
spring to my mind straight away with this:
- is getting the PerlIO * for STDOUT to right thing to be doing anyway?
- if items  2, do we need to handle the UTF8-ness of each of those 
items individually before we join them?
- we need to code this in such a way as to remain backwards compatible 
with older Perls.

Anyway, it's a start.

If not, we should log it in the STATUS file and hopefully someone will 
have the time and inclination to solve it. 
Hopefully the above stab at it will encourage somebody to have a serious 
look.



In any case a simple test that reproduces the problem will be needed. 
This test program reproduces the problem:

   use 5.008;
   use Encode;
   print Content-type: text/plain\n\n, decode('iso-8859-1', 'ü');
Use LWP's get program to get that from an Apache/mod_cgi setup, run it 
through UNIX's od -c (get http://localhost/cgi-bin/test.pl | od

Re: Combining authen-handler with mod_auth

2003-07-15 Thread martin

On Mon, 14 Jul 2003 23:26:06 -0500 (CDT), Geoffrey Young wrote:

  Instead of trying to cram multiple perl-script into the same Authen
  phase, which btw could not be done without patching Apache and/or
  mod_perl,
 
 if by perl-script you mean mod_perl handlers, that's not really true.
 currently, mod_perl will run all configured PerlAuthenHandlers until one
 returns an Apache error (401, 500, etc).  when I get back from vacation in a
 few weeks, the first item on my list is changing this so that mod_perl
 behaves exactly like Apache: namely, that the first OK passes control to the
 next phase and terminates the current phase.

Sorry, I was not clear enough. The problem is that I need to run mp2-handlers before 
_and_
after the actual mod_auth (compiled apache binary) module. But apparently mp2 runs 
_all_
its Authen-handlers at the same time, ie it is not possible to split handling in the 
same
phase between mp2 and apache -- something that I must do (afaik?) because of the
ledger-counting.

  By keeping count like this (and assuming it works in a real
  situation), one can device lots of cool ways to add login and password
  policies. Just change relevant part in the Bouncer/Ledger.
 
 I'll take a closer look at this in a few weeks when I'm back full time, but
 right now I think I would have coded it all in the PerlAuthenHandler - I
 think that basic housekeeping like last-auth, etc all are ok things to put
 into that phase, so it makes a certain amount of sense to add your denial
 rules to that phase as well.

Ok. But when I tested it in practice it failed because I need perl-Authen-code to run 
just
before, and just after mod_auth has finished. The only way I could figure out how to do
that was to put Bouncer in the Access phase and Ledger in the FixUp phase. On other 
words
abusing the phases somewhat. 

[stuff added :-) ]

  # Find userinfo in cache. If user is banned, return
  # HTTP_UNAUTHORIZED else let him through to next handler
  PerlAccessHandler MyApache::Bouncer

  # The actual auth module. Patched so it creates an apache
  # request note if user is unauthorized + let request through
  # to next handler (DECLINED) _even tho_ user failed!
  AuthExternal wicauth

  # If apache note contains current user, update cache (nfailures
  # count) and return HTTP_UNAUTHORIZED or return OK
  PerlFixUpHandler MyApache::Ledger

 anyway, I'm essentially offline for the next two weeks, but if you ping me
 after that we can talk more.
 good luck

Thanks!

Apache::Registry in mod_perl 2

2003-07-15 Thread ColinB

This page:

http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends

says that mod_perl 2's ModPerl::Registry does not chdir() into the
script's directory, wheras mod_perl 1's Apache::Registry DOES chdir().
It also says that this will eventually be fixed by the time mod_perl 2
is released, and in the meantime you can use the Apache::Registry
(which is part of mod_perl 1) in mod_perl 2.

As I will be trying to get some old scripts working in mod_perl 2, it
seems prudent to use Apache::Registry.

So how can I go about installing just Apache::Registry from the
mod_perl 1 tar file without having to install ALL of mod_perl 1 ?

Colin


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: informational notice in Makefile.PL

Randy Kobes wrote:
On Mon, 14 Jul 2003, Stas Bekman wrote:

[ ... ]

Are you talking about the dependencies list? by 'the current
state of affairs with mod_perl 2.0', you mean that it's not
indexed by PAUSE. It's available from CPAN.
Actually, once it gets indexed by CPAN it'll break all the
other modules which specify mod_perl (1.0) as a dependency and
won't work with 2.0.


Perhaps it might be an idea, at this stage, to recommend to
module authors that, if their package is for mod_perl 1 only, to
use a module like Apache::Constants in their PREREQ_PM (ie,
something available only within mod_perl 1), and if it's for
mod_perl 2 only, use something like Apache::Const, or something
available only with mod_perl 2. This won't help existing
packages, but it would at least alert people that a problem is on
the horizon.
Good idea, Randy. And there is an even more intuitive solution: either require 
Apache or Apache2, depending on which version you need.

To help in this, perhaps it would be worthwhile to promote the
use of Module::Install? A package (Module::Install::mod_perl?)
could be made which would make available a function to test for
the mod_perl version a user has, and then decide if this is
appropriate for the package about to be installed. If the
required mod_perl version isn't present, one could either offer
to add the required version to PREREQ_PM, or else just die, as
automated installs of mod_perl can be tricky. A lot of the code
for this could be extracted from Apache::Test; Stas, you've also
worked through this logic in making packages that include
different versions for different mod_perl versions.  Only the
package author need have Module::Install::* when constructing the
Makefile.PL - the necessary stuff for the added functionality is
added to the distribution, making it transparent to the user.
Yup, I was planning to look at how Module::Install solves this issue. 
Unfortunatelly I've missed the BOF last week at the OSCon that was discussing 
this module :(

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [mp2] Apache::Cookie

Swen Schillig wrote:
Are there any plans to have Apache::Cookie or does
mp2 code always has to use CGI if there are cookies needed ?
Apache::Cookie is a part of the libapreq-2 library. It'll become available as 
soon as Apache::Request is released. You are more then welcome to join the 
libapreq list and help debug the current version. For more info see:
http://httpd.apache.org/apreq/



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [RFC] web-messaging application for mod_perl

2003-07-15 Thread John Saylor

hi

( 03.07.14 20:14 -0700 ) Adi Fairbank:
 ( I wouldn't want to have any piece of software named after me... just
 my personal style.  Software lives for too long, especially open
 source.  It would still be called that long after I'm dead. )

don't be too sure. no one may call it anything at all in about 6 months
...

 Here are the possibilities:

what about
Apache::Messaging::Web

to leave room for other messaging modules to share this namespace
[::Pager or ::Fax ...]

-- 
\js

Re: Bareword Apache::OK not allowed, Apache::PerlSection

2003-07-15 Thread Alexander Newald

- Original Message - 
From: Stas Bekman [EMAIL PROTECTED]
To: Alexander Newald [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 12:26 PM
Subject: Re: Bareword Apache::OK not allowed, Apache::PerlSection

 Alexander Newald wrote:
  Hello,

  I have installed mod_perl2

  (http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz,
  mod_perl-1.99_09)

  with

  cd mod_perl-1.99_09
  perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache2

  and added

  LoadModule perl_module modules/mod_perl.so
  Perl 
  $ServerName = `hostname`;
  /Perl

  to my httpd.conf

  When I try to start the server I get

  [Mon Jul 14 14:46:25 2003] [error] failed to resolve handler
  `Apache::PerlSection'
  Syntax error on line 321 of /etc/httpd/httpd.conf:
  Bareword Apache::OK not allowed while strict subs in use at
  /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/PerlSection.pm line 47.
  BEGIN not safe after errors--compilation aborted at
  /usr/lib/perl5/site_perl/5.8.0/i686-linux/Apache/PerlSection.pm line 58.
  Compilation failed in require at (eval 2) line 3.

  It doesn't matter what I put between Perl  /Perl

  Any hints?

 works fine for me, may be you need to add:

 PerlModule Apache2

 before your first Perl section?

 Also I'd suggest to always run your mod_perl server with:

 PerlSwitches -wT

Hello,

I have done all this. As I had some more spare time I tried the cvs version
and found that cvs version is working. The code of PerlSection.pm differs
from the current tar and the cvs

Is this a bug and I should post a bug report on it?

Alexander Newald

Re: Undocumented behaviour in Apache-print()?

Steve Hay wrote:

5.8.0 is a pretty new perl version, which provides the new
functionality, and it seems that hardly anybody has been using the UTF
stuff with mod_perl.

5.8.0 is actually a couple of days short of being one year old (happy
birthday!), which is increasingly not that new any more. 5.8.1 should
be out soon too.
I meant that it was too new to be embraced by the crowd. it'll probably take a
few more years before this will happen. In any case, this is just an excuse ;)

As for hardly anybody using UTF8 stuff with mod_perl... I didn't think
that I was until I realised that most XML parsers (certainly the two
that I most uses -- XML::LibXML and XML::DOM) return all their data in
Perl's internal UTF-8 format! Then the penny dropped that I was
actually using it rather a lot :-)
I thought XML was dead. Do people still use this archaic technology? I went to
this session at this OS conference with many k00l ppls and there was this
dude[1] who said that YAML is the future. Next they started talking about
animals, and for some reason everybody liked ponie. All well, orange people
[2], orange sites [3], orange ponies [4], jetlag, too many flights, too little
sleep...

1:
http://husk.org/pics/imgs/people/perl/london.pm_ingy_2001-07-30/ingy_nino_tired.jpg
2:
http://husk.org/pics/imgs/people/perl/london.pm_ingy_2001-07-30/acme_perl_hacker_scary.jpg
3: http://search.cpan.org/
4: http://ponie.kwiki.org/ http://www.poniecode.org/

;)

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com

Re: untainting PATH in mod_perl

Peter B. Ensch wrote:

FWIW, I use the following code when I need to use ``|qx:

local $ENV{PATH} = /bin:/usr/bin;
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
But this code must be used in each scope where you intend to use 
backticks, a system call Etc. Is there no way to untaint your
PATH environment one time for the script or handler?
If you write code used by other people this is probably the only way to go. 
This is because you want to control the setting. What if PATH gets untainted 
at the server startup, but then some other module sets a new tainted value to 
$ENV{PATH}? So it's a good habit to have it local to the code that you run.

Besides helps to avoid forking external processes. If you can rewrite your code:

 foreach(`/bin/ls $path`) {
   do something
 }
(which is probably not the real code), not to `` but to read the file in, and 
process it, you eliminate the whole problem altogether. I realize that this is 
not always possible.

How about abstracting untaint and `` into a single function:

sub backticks {
  local $ENV{PATH} = /bin:/usr/bin;
  local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
  qx(@_);
}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Bareword Apache::OK not allowed, Apache::PerlSection

[...]
works fine for me, may be you need to add:

PerlModule Apache2

before your first Perl section?

Also I'd suggest to always run your mod_perl server with:

PerlSwitches -wT


Hello,

I have done all this. As I had some more spare time I tried the cvs version
and found that cvs version is working. The code of PerlSection.pm differs
from the current tar and the cvs
Is this a bug and I should post a bug report on it?
That explains why I couldn't reproduce the problem, thanks. If it works in cvs 
why reporting a bug? Philippe has been working on PerlSections recently, so 
yes the cvs version is different from 1.99_09.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Undocumented behaviour in Apache-print()?

[putting the test case on the top]

Steve Hay wrote:

 In any case a simple test that reproduces the problem will be needed.


 This test program reproduces the problem:

use 5.008;
use Encode;
print Content-type: text/plain\n\n, decode('iso-8859-1', 'ü');

 Use LWP's get program to get that from an Apache/mod_cgi setup, run it
 through UNIX's od -c (get http://localhost/cgi-bin/test.pl | od -c)
 and you get:

000 374
001

 Try the same from an Apache/mod_perl setup and you get:

000 303 274
002

 i.e. the double-byte UTF-8 character representing ü that has been output
 is converted back to ü by Perl's print() [ü is character 252, octal
 374], but is left as the two bytes by Apache's print().

 I've actually re-built my mod_perl using the half-formed patch given
 above and it fixes this particular test case!
On my linux box it's 'od -b', 'od -c' prints the actual ascii chars.

I've tested mp2 and it has the same problem. I've used a different version of 
your test:

#!/usr/bin/perl -w
use utf8;
print Content-type: text/plain\n\n;
$a = \xC3\xBC;
utf8::decode($a); print $a;
which gives the same char, as in:
% perl -le '$a = \xC3\xBC; use utf8; utf8::decode($a); print $a;'
ü
mod_perl 1.0 and 2.0 respond with:

GET 'http://localhost:8002/cgi-bin/test.pl' | od -b
000 303 274
and moc_cgi with
000 374

Hmm.  We really need somebody who understands the internals of Perl and 
mod_perl better than me, but here's a first stab at it:

The Perl source code contains a pp_print() function in pp_hot.c which 
I presume is basically CORE::print().  It makes use of a do_print() 
function.  I think that function comes from doio.c, although it's 
actually called Perl_do_print() there.  That function does some stuff 
with the UTF-8 flag, which I guess is the sort of thing that we're 
after.  Here's a chunk of Perl_do_print() from Perl 5.8.0:

   if (PerlIO_isutf8(fp)) {
   if (!SvUTF8(sv))
   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
   }
   else if (DO_UTF8(sv)) {
   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
ckWARN_d(WARN_UTF8))
   {
   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
   }
   }
I think what this does is look to see if the fp (a PerlIO *) has the 
:utf8 encoding layer.  If so, then it upgrades the sv to UTF8 (which 
is always possible).  If not, then it looks to see if the bytes pragma 
is enabled.  If not, then it downgrades the sv from UTF8 (which is not 
always possible -- if that fails and the UTF8 warnings category is 
enabled then it outputs the good ol' Wide character in print warning).

I have attempted to shoe-horn this into mod_perl's print() method (in 
src/modules/perl/Apache.xs).  Here's the diff against mod_perl 1.28:  
[Unfortunately, I've had to comment-out the first part of that if 
block, because I got an unresolved external symbol error relating to the 
PerlIO_isutf8() function otherwise (which may be because that function 
isn't documented in the perlapio manpage).]

--- Apache.xs.orig2003-06-06 12:31:10.0 +0100
+++ Apache.xs2003-07-15 12:20:42.0 +0100
@@ -1119,12 +1119,25 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+/*PerlIO *fp = PerlIO_stdout();*/
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+/*if (PerlIO_isutf8(fp)) {
+if (!SvUTF8(sv))
+sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+}
+else*/ if (DO_UTF8(sv)) {
+if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ ckWARN_d(WARN_UTF8))
+{
+Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+}
+}
+
PUSHMARK(sp);
XPUSHs(rp);
XPUSHs(sv);
Besides the problem with PerlIO_isutf8(), there are other problems that 
spring to my mind straight away with this:
- is getting the PerlIO * for STDOUT to right thing to be doing anyway?
- if items  2, do we need to handle the UTF8-ness of each of those 
items individually before we join them?
- we need to code this in such a way as to remain backwards compatible 
with older Perls.
looks like this is the main question. Do we handle utf8 only for perl 5.8?

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [MP2 - BUG ?] Issue handing Apache config. error messages

Issac Goldstand wrote:
[...]
(Starting

with mor_perl 2)...  I'm toying with the idea of starting the porting
tutorial, but I want to make sure it's written well for clueless people
(which I probably still at least half count as :-)) and with accurate
content.
porting or starting? We already have a porting guide:
http://perl.apache.org/docs/2.0/user/porting/porting.html
a porting reference:
http://perl.apache.org/docs/2.0/user/porting/compat.html


Right - I read it, and it's reference.  It's not a good guide.  A guide
should start with the basics.  The mp_1 guide is one of the most beautiful
pieces of electronic documentation in existance!  It should be a book (I
know: practical mod_perl)  Seriously though - the guide is what personally
turned me on to mod_perl, but the above two documents make me shiver and
stay the hell away from mp_2.  What's needed is a good friendly piece of
documentation to get people moving... to mp_2
Certainly. Just remember that the guide is 4 years old. The 2.0 docs are a few 
 months old. So all we need is to make it better.

and even getting started:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html


Will look at it shortly - Let's not bite off more than we can chew in one
mouthful.

I'd suggest to improve these docs where approapriate and start a new doc
only

if it really doesn't fit into the existing docs.


I'm just not sure if it *does* fit...
Let's see what you come up with and we can decides whether it fits or not. The 
idea is to avoid forks and have people collaborate on the single best source 
of documentation, rather than private projects. Private projects could be 
good, but given the complexity of mod_perl, having a good single source of 
documentation is a great boon for its acceptance.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Apache::Registry in mod_perl 2

ColinB wrote:
This page:

http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends

says that mod_perl 2's ModPerl::Registry does not chdir() into the
script's directory, wheras mod_perl 1's Apache::Registry DOES chdir().
It also says that this will eventually be fixed by the time mod_perl 2
is released, and in the meantime you can use the Apache::Registry
(which is part of mod_perl 1) in mod_perl 2.
As I will be trying to get some old scripts working in mod_perl 2, it
seems prudent to use Apache::Registry.
You have omitted this sentence:

  However you will have problems if you are using
  anything but the preforked MPM, the main reason why
  ModPerl::Registry doesn't chdir().
So how can I go about installing just Apache::Registry from the
mod_perl 1 tar file without having to install ALL of mod_perl 1 ?
simply copy it into one of the dirs in your @INC.

You will also need to load Apache::compat for it to work.

Alternatively you can subclass ModPerl::Registry's chdir_file function to 
perform chdir, like Apache::Registry does.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Undocumented behaviour in Apache-print()?

2003-07-15 Thread Steve Hay

Stas Bekman wrote:

I have attempted to shoe-horn this into mod_perl's print() method (in 
src/modules/perl/Apache.xs).  Here's the diff against mod_perl 
1.28:  [Unfortunately, I've had to comment-out the first part of that 
if block, because I got an unresolved external symbol error 
relating to the PerlIO_isutf8() function otherwise (which may be 
because that function isn't documented in the perlapio manpage).]

--- Apache.xs.orig2003-06-06 12:31:10.0 +0100
+++ Apache.xs2003-07-15 12:20:42.0 +0100
@@ -1119,12 +1119,25 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+/*PerlIO *fp = PerlIO_stdout();*/
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+/*if (PerlIO_isutf8(fp)) {
+if (!SvUTF8(sv))
+sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+}
+else*/ if (DO_UTF8(sv)) {
+if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ ckWARN_d(WARN_UTF8))
+{
+Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in 
print);
+}
+}
+
PUSHMARK(sp);
XPUSHs(rp);
XPUSHs(sv);

Besides the problem with PerlIO_isutf8(), there are other problems 
that spring to my mind straight away with this:
- is getting the PerlIO * for STDOUT to right thing to be doing anyway?
- if items  2, do we need to handle the UTF8-ness of each of those 
items individually before we join them?
- we need to code this in such a way as to remain backwards 
compatible with older Perls.


looks like this is the main question. Do we handle utf8 only for perl 
5.8? 
It's only Perl 5.8 that has the special UTF-8 flag which the functions 
above all operate with respect to.  If a Perl variable contains a 
sequence of bytes that make up a valid UTF-8 character, but the string 
is not flagged with Perl's special flag, then Perl's built-in print() 
doesn't do this automatic conversion anyway.

IOW,

   print Content-type: text/plain\n\n;
   $a = \xC3\xBC;
   print $a;
retrieved from a mod_cgi server produces (via od -b / od -c):

   000 303 274
   002
Perl 5.6 and older don't have the UTF-8 flag and hence don't do any 
automatic conversion via print().  Therefore, mod_perl's print() should 
not have the difference from Perl's print() that exists in 5.8, so no 
change should be required.

Sure enough, looking at the doio.c source file in Perl 5.6.1, the 
entire chunk of code that I half-inched above is not present.

Steve

Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)

2003-07-15 Thread Bill Marrs

At 04:24 AM 7/15/2003, Stas Bekman wrote:
Philippe M. Chiasson wrote:
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:

This fixed the bug for me.
Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
-1, this is a wrong solution. print ; should flush just like it did in 
mod_perl 1.0 if $| == 1; Consider this script:

print Content-type: text/plain\n\n;
local $| = 0;
print start\n\n;
local $| = 1;
print ;
sleep 5;
local $| = 0;
print end\n;
print , must immediately flush the buffered data, since $| has changed 
from 0 to 1.
This may be naive, but might it not flush the output buffer at the 4th line 
(local $| = 1;)?  ...or does the flush only happen when print is 
called.  Having to call print  seems cumbersome to do a flush, but maybe 
that's just the way Perl works?

One thing that could help is if someone could take the time to write a
test for this bug.
Unfortunately I don't seem to be able to reproduce the problem, so I can't 
debug the problem. It could be a bug on the mod_deflate's behalf as well. 
Philippe, were you able to reproduce the problem with Bill's setup? I was 
writing a test, but couldn't get it to fail... may be because i was using 
2.0.47. Bill, do you have the problem with the latest apache version?
Did you see my note in the original post about this working fine under 
mod_cgi, but causing the 20014:Error only under mod_perl?  This seemed to 
point the finger squarely at mod_perl.

I could upgrade to 2.0.47, but it seems unlikely that it would fix 
this.  Are you sure you're running a mod_perl without Philippe's fix (in 
Apache__RequestIO.h), I assumed he eventually checked it in.

Also Bill, why do you have this setup:

Location /perl
  AddOutputFilterByType DEFLATE text/*
  SetOutputFilter DEFLATE
/Location
why adding it twice? You need only the latter inside Location, or 
alternatively only the former outside Location if you want it to be set 
globally:
http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype
Ah, I misunderstood the mod_deflate docs.  I think at the time, it didn't 
seem to work with just one of them in-place, so I added the 
other.  *SHRUG*  I can't say I'm a pro at Apache config files, I just 
tinker until it works.  I assume this is irrelevant to the bug, though.

-bill

Re: untainting PATH in mod_perl

2003-07-15 Thread Peter Ensch

On Tue, Jul 15, 2003 at 04:30:35PM +0300, Stas Bekman wrote:
 Peter B. Ensch wrote:
 
 FWIW, I use the following code when I need to use ``|qx:
 
 local $ENV{PATH} = /bin:/usr/bin;
 local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
 
 But this code must be used in each scope where you intend to use 
 backticks, a system call Etc. Is there no way to untaint your
 PATH environment one time for the script or handler?
 
 If you write code used by other people this is probably the only way to go. 
 This is because you want to control the setting. What if PATH gets 
 untainted at the server startup, but then some other module sets a new 
 tainted value to $ENV{PATH}? So it's a good habit to have it local to the 
 code that you run.
 
 Besides helps to avoid forking external processes. If you can rewrite your 
 code:
 
  foreach(`/bin/ls $path`) {
do something
  }
 
 (which is probably not the real code), not to `` but to read the file in, 
 and process it, you eliminate the whole problem altogether. I realize that 
 this is not always possible.
 
 How about abstracting untaint and `` into a single function:
 
 sub backticks {
   local $ENV{PATH} = /bin:/usr/bin;
   local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
   qx(@_);
 }
 

Stas,

Thanks for your explanation and suggestion. I'm a lot clearer on this
issue now.

P.

-- 

^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Peter Ensch,
[EMAIL PROTECTED]   A-1140   (214) 480 2333
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^

Re: module ported and doc addition...

Stas Bekman wrote:

Shannon Eric Peevey wrote:
[...]
Also, you don't realy have to do that. The old ala mp1 style works 
just fine.

use Apache::Const qw(OK DECLINED)

sub handler {

   return OK;
} 


Well...  I must have been smoking crack, 'cause I seem to remember a 
simple:

return  MP2 ? Apache::OK : OK

throwing an error, hence, the change to:

MP2 ? Apache::OK : Apache::Constants::OK

Now that I test it, though, there doesn't seem to be a problem...  :P


May be you haven't been importing the constant. These two aren't the 
same:

use Apache::Const qw(OK DECLINED);
use Apache::Const -compile = qw(OK DECLINED);
the latter only compiles the constants, the former compiles and 
imports it.

[...] 
Here is the code:

BEGIN {
   if (MP2) {
   require Apache::Const;
   require Apache::Access;
   require Apache::Connection;
   require Apache::Log;
   require Apache::RequestRec;
   require Apache::RequestUtil;
   Apache::Const-import(-compile = 'HTTP_UNAUTHORIZED','OK');
   } else {
   require Apache::Constants;
   Apache::Constants-import('HTTP_UNAUTHORIZED','OK');
   }
}
(Or, variations upon it...)  As I've said, though, my code is dying with 
an error on Apache::Constants anymore  If I hit it again, I will 
post the error message that I was getting.

thanks,
speeves
cws

Re: [mp2] Apache::Cookie

On Tue, 2003-07-15 at 06:43, Swen Schillig wrote:
 Are there any plans to have Apache::Cookie or does
 mp2 code always has to use CGI if there are cookies needed ?

Apache::Cookie is part of libapreq (along with Apache::Request), so you
should follow libapreq development for this.

- Perrin

Re: Apache::Registry in mod_perl 2

On Tue, 2003-07-15 at 08:44, ColinB wrote:
 So how can I go about installing just Apache::Registry from the
 mod_perl 1 tar file without having to install ALL of mod_perl 1 ?

Just copy the Apache/Registry.pm file into the same directory that all
your other Apache:: modules are in.

- Perrin

Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error stringnot specified)

Bill Marrs wrote:
At 04:24 AM 7/15/2003, Stas Bekman wrote:

Philippe M. Chiasson wrote:

On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:

This fixed the bug for me.


Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)


-1, this is a wrong solution. print ; should flush just like it did 
in mod_perl 1.0 if $| == 1; Consider this script:

print Content-type: text/plain\n\n;
local $| = 0;
print start\n\n;
local $| = 1;
print ;
sleep 5;
local $| = 0;
print end\n;
print , must immediately flush the buffered data, since $| has 
changed from 0 to 1.


This may be naive, but might it not flush the output buffer at the 4th 
line (local $| = 1;)?  ...or does the flush only happen when print is 
called.  Having to call print  seems cumbersome to do a flush, but 
maybe that's just the way Perl works?
There is $r-rflush for this purpose. This is not a perl API, but Apache API. 
You can also use IO::File or other IO packages that extend perl to provide 
this kind of API.

But this is how perl works, so we have to preserve it under mod_perl.

One thing that could help is if someone could take the time to write a
test for this bug.


Unfortunately I don't seem to be able to reproduce the problem, so I 
can't debug the problem. It could be a bug on the mod_deflate's behalf 
as well. Philippe, were you able to reproduce the problem with Bill's 
setup? I was writing a test, but couldn't get it to fail... may be 
because i was using 2.0.47. Bill, do you have the problem with the 
latest apache version?


Did you see my note in the original post about this working fine under 
mod_cgi, but causing the 20014:Error only under mod_perl?  This seemed 
to point the finger squarely at mod_perl.
If I was able to reproduce it I could tell, but I don't seem to.

I could upgrade to 2.0.47, but it seems unlikely that it would fix 
this.  Are you sure you're running a mod_perl without Philippe's fix (in 
Apache__RequestIO.h), I assumed he eventually checked it in.
No, Philippe hasn't committed it, neither I have used it. If you can test with 
2.9.47 that will help. Otherwise I'll later try with .46 as well.

Also Bill, why do you have this setup:

Location /perl
  AddOutputFilterByType DEFLATE text/*
  SetOutputFilter DEFLATE
/Location
why adding it twice? You need only the latter inside Location, or 
alternatively only the former outside Location if you want it to be 
set globally:
http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype


Ah, I misunderstood the mod_deflate docs.  I think at the time, it 
didn't seem to work with just one of them in-place, so I added the 
other.  *SHRUG*  I can't say I'm a pro at Apache config files, I just 
tinker until it works.  I assume this is irrelevant to the bug, though.
I'm not sure if your config doesn't insert the filter twice. Need to check 
whether SetOutputFilter overrides AddOutputFilterByType as well.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: module ported and doc addition...

Stas Bekman wrote:

Shannon Eric Peevey wrote:
[...]
Also, you don't realy have to do that. The old ala mp1 style works 
just fine.

use Apache::Const qw(OK DECLINED)

sub handler {

   return OK;
} 


Well...  I must have been smoking crack, 'cause I seem to remember a 
simple:

return  MP2 ? Apache::OK : OK

throwing an error, hence, the change to:

MP2 ? Apache::OK : Apache::Constants::OK

Now that I test it, though, there doesn't seem to be a problem...  :P


May be you haven't been importing the constant. These two aren't the 
same:

use Apache::Const qw(OK DECLINED);
use Apache::Const -compile = qw(OK DECLINED);
the latter only compiles the constants, the former compiles and 
imports it.

[...]

Just started working on Apache-AuthNTLM and came across the cross 
reference that you posted awhile back.  This might be where I got it:

 sub handler {
 # ...
 return MP2 ? Apache::OK : Apache::Constants::OK;
 }
 1;
in the mod_perl 1.0 and 2.0 Constants Coexistence section of:

http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Constants_

speeves
cws

Re: Undocumented behaviour in Apache-print()?

Steve Hay wrote:
Stas Bekman wrote:

I have attempted to shoe-horn this into mod_perl's print() method (in 
src/modules/perl/Apache.xs).  Here's the diff against mod_perl 
1.28:  [Unfortunately, I've had to comment-out the first part of that 
if block, because I got an unresolved external symbol error 
relating to the PerlIO_isutf8() function otherwise (which may be 
because that function isn't documented in the perlapio manpage).]

--- Apache.xs.orig2003-06-06 12:31:10.0 +0100
+++ Apache.xs2003-07-15 12:20:42.0 +0100
@@ -1119,12 +1119,25 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+/*PerlIO *fp = PerlIO_stdout();*/
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+/*if (PerlIO_isutf8(fp)) {
+if (!SvUTF8(sv))
+sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+}
+else*/ if (DO_UTF8(sv)) {
+if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ ckWARN_d(WARN_UTF8))
+{
+Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in 
print);
+}
+}
+
PUSHMARK(sp);
XPUSHs(rp);
XPUSHs(sv);

Besides the problem with PerlIO_isutf8(), there are other problems 
that spring to my mind straight away with this:
- is getting the PerlIO * for STDOUT to right thing to be doing anyway?
- if items  2, do we need to handle the UTF8-ness of each of those 
items individually before we join them?
- we need to code this in such a way as to remain backwards 
compatible with older Perls.


looks like this is the main question. Do we handle utf8 only for perl 
5.8? 


It's only Perl 5.8 that has the special UTF-8 flag which the functions 
above all operate with respect to.  If a Perl variable contains a 
sequence of bytes that make up a valid UTF-8 character, but the string 
is not flagged with Perl's special flag, then Perl's built-in print() 
doesn't do this automatic conversion anyway.
Yes.

Apps wanting to handle utf will need to 'require 5.008;' as in your example.

IOW,

   print Content-type: text/plain\n\n;
   $a = \xC3\xBC;
   print $a;
retrieved from a mod_cgi server produces (via od -b / od -c):

   000 303 274
   002
yup, because you need to add utf8::decode($a); before printing $a. Which your 
version does as well.

Perl 5.6 and older don't have the UTF-8 flag and hence don't do any 
automatic conversion via print().  Therefore, mod_perl's print() should 
not have the difference from Perl's print() that exists in 5.8, so no 
change should be required.

Sure enough, looking at the doio.c source file in Perl 5.6.1, the 
entire chunk of code that I half-inched above is not present.
So you suggest that we copy this functionality from Perl. So if need to #ifdef 
it for 5.8.0.

 I have attempted to shoe-horn this into mod_perl's print() method (in
 src/modules/perl/Apache.xs).  Here's the diff against mod_perl 1.28:
 [Unfortunately, I've had to comment-out the first part of that if
 block, because I got an unresolved external symbol error relating to the
 PerlIO_isutf8() function otherwise (which may be because that function
 isn't documented in the perlapio manpage).]

 --- Apache.xs.orig2003-06-06 12:31:10.0 +0100
 +++ Apache.xs2003-07-15 12:20:42.0 +0100
 @@ -1119,12 +1119,25 @@
 SV *sv = sv_newmortal();
 SV *rp = ST(0);
 SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
 +/*PerlIO *fp = PerlIO_stdout();*/

 if(items  2)
 do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
 else
 sv_setsv(sv, ST(1));

 +/*if (PerlIO_isutf8(fp)) {
 +if (!SvUTF8(sv))
 +sv_utf8_upgrade(sv = sv_mortalcopy(sv));
 +}
 +else*/ if (DO_UTF8(sv)) {
 +if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
 + ckWARN_d(WARN_UTF8))
 +{
 +Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
 +}
 +}
 +
 PUSHMARK(sp);
 XPUSHs(rp);
 XPUSHs(sv);

 Besides the problem with PerlIO_isutf8(),
mod_perl 1.x doesn't use perlio, hence you have this problem. adding:

#include perlio.h

should resolve it I think.

 there are other problems that
 spring to my mind straight away with this:
 - is getting the PerlIO * for STDOUT to right thing to be doing anyway?
PerlIO *fp = IoOFP(GvIOp(defoutgv))

 - if items  2, do we need to handle the UTF8-ness of each of those
 items individually before we join them?
I'm not sure, how perl handles this?

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Virtual Host Logging Perl Script

2003-07-15 Thread Jez Hancock

On Tue, Jul 15, 2003 at 01:32:11PM +0300, Stas Bekman wrote:
 Jez Hancock wrote:
 My question is: would it be possible to use mod_perl in some way to
 perform the function of the script?  In testing the speed of the script
 seems reasonable enough, is there a better way to do what I'm doing
 below?
 
 Take a look at:
 http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler
 a similar code will work for mp1 if you don't use 2.0.
Much obliged, that does look to be something I could use.  Reminds me I
need to be locking the logfile as well ;)

Thanks Stas,
-- 
Jez

http://www.munk.nu/

Re: [mp2] Apache::Cookie

2003-07-15 Thread Joe Schaefer

Perrin Harkins [EMAIL PROTECTED] writes:

 On Tue, 2003-07-15 at 06:43, Swen Schillig wrote:
  Are there any plans to have Apache::Cookie or does
  mp2 code always has to use CGI if there are cookies needed ?
 
 Apache::Cookie is part of libapreq (along with Apache::Request), so you
 should follow libapreq development for this.

Now would be an especially good time for the adventurous
to try out libapreq-2, since user feedback will accelerate
the release process.  The preliminary docs for mp2's Apache::Cookie
are online at

  http://httpd.apache.org/~joes/libapreq-2/group__XS__Cookie.html

Access to the cvs repository for httpd-apreq-2 is described
at the bottom of

  http://httpd.apache.org/apreq/

-- 
Joe Schaefer

Re: Virtual Host Logging Perl Script

On Tue, 2003-07-15 at 14:27, Jez Hancock wrote:
 On Tue, Jul 15, 2003 at 01:32:11PM +0300, Stas Bekman wrote:
  Take a look at:
  http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler
  a similar code will work for mp1 if you don't use 2.0.
 Much obliged, that does look to be something I could use.  Reminds me I
 need to be locking the logfile as well ;)

Actually, if you are just printing one short line I think you'll be fine
without locking on unix systems.  See the FAQ:
http://www.perldoc.com/perl5.8.0/pod/perlfaq5.html#All-I-want-to-do-is-append-a-small-amount-of-text-to-the-end-of-a-file.--Do-I-still-have-to-use-locking-

- Perrin

Re: module ported and doc addition...

Shannon Eric Peevey wrote:
Stas Bekman wrote:

Shannon Eric Peevey wrote:
[...]
Also, you don't realy have to do that. The old ala mp1 style works 
just fine.

use Apache::Const qw(OK DECLINED)

sub handler {

   return OK;
} 




Well...  I must have been smoking crack, 'cause I seem to remember a 
simple:

return  MP2 ? Apache::OK : OK

throwing an error, hence, the change to:

MP2 ? Apache::OK : Apache::Constants::OK

Now that I test it, though, there doesn't seem to be a problem...  :P


May be you haven't been importing the constant. These two aren't the 
same:

use Apache::Const qw(OK DECLINED);
use Apache::Const -compile = qw(OK DECLINED);
the latter only compiles the constants, the former compiles and 
imports it.

[...]

Just started working on Apache-AuthNTLM and came across the cross 
reference that you posted awhile back.  This might be where I got it:

 sub handler {
 # ...
 return MP2 ? Apache::OK : Apache::Constants::OK;
 }
 1;
in the mod_perl 1.0 and 2.0 Constants Coexistence section of:

http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Constants_ 
Yup, in mod_perl 2.0 we should better use fully qualified constants, because 
now we have APR:: and Apache:: constants, hence the docs use this style 
everywhere. However the mp1's style works as well. Though I haven't checked 
whether there are any overlaps if the top level is removed.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Virtual Host Logging Perl Script

Perrin Harkins wrote:
On Tue, 2003-07-15 at 14:27, Jez Hancock wrote:

On Tue, Jul 15, 2003 at 01:32:11PM +0300, Stas Bekman wrote:

Take a look at:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler
a similar code will work for mp1 if you don't use 2.0.
Much obliged, that does look to be something I could use.  Reminds me I
need to be locking the logfile as well ;)


Actually, if you are just printing one short line I think you'll be fine
without locking on unix systems.  See the FAQ:
http://www.perldoc.com/perl5.8.0/pod/perlfaq5.html#All-I-want-to-do-is-append-a-small-amount-of-text-to-the-end-of-a-file.--Do-I-still-have-to-use-locking-
Is this still correct in the threaded environment where the filehandle is 
shared across several threads? The writes are atomic 4k or so, indeed, but 
what happens if two threads write to the same filehandle at the same time on 
the SMP machine? Won't things get messed up? I haven't checked, perhaps perlio 
already provides an internal locking. Arthur would be a good person to ask.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: Virtual Host Logging Perl Script

On Tue, 2003-07-15 at 16:11, Stas Bekman wrote:
 Is this still correct in the threaded environment where the filehandle is 
 shared across several threads?

Why would the filehandle be shared?  Wouldn't you open a new handle in
each thread?

I expect this would be fine, since the behavior is enforced by the
system library rather than by Perl.  You can always use flock if you're
feeling paranoid about it though.

- Perrin

Re: Virtual Host Logging Perl Script

2003-07-15 Thread Jez Hancock

On Tue, Jul 15, 2003 at 02:39:18PM -0400, Perrin Harkins wrote:
 On Tue, 2003-07-15 at 14:27, Jez Hancock wrote:
  Much obliged, that does look to be something I could use.  Reminds me I
  need to be locking the logfile as well ;)
 
 Actually, if you are just printing one short line I think you'll be fine
 without locking on unix systems.  See the FAQ:
 http://www.perldoc.com/perl5.8.0/pod/perlfaq5.html#All-I-want-to-do-is-append-a-small-amount-of-text-to-the-end-of-a-file.--Do-I-still-have-to-use-locking-
Ok thanks Perrin.  The script is actually running nicely as it is right
now on a server hosting 50 or so domains, although admittedly it's not
taking a massive number of hits (10,000 or so per day).

Does anyone how one could log errorlog entries in a similar manner to
the script above - ie pipe the errorlog to a script which appends one
copy of the error entry to a main error logfile and another copy to the
virtual host's error logfile?

-- 
Jez

http://www.munk.nu/

Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)

2003-07-15 Thread Bill Marrs


I could upgrade to 2.0.47, but it seems unlikely that it would fix 
this.  Are you sure you're running a mod_perl without Philippe's fix (in 
Apache__RequestIO.h), I assumed he eventually checked it in.
No, Philippe hasn't committed it, neither I have used it. If you can test 
with 2.9.47 that will help. Otherwise I'll later try with .46 as well.
I just upgraded to Apache 2.0.47 and the latest CVS of mp2 and I'm 
reproducing it, same as I originally reported.

I tried a few variations to see if I could find other factors, but didn't 
have much luck.  The server I'm testing on is live (runs a small site), so 
I'm somewhat limited in what I can do.  But, I tried removing mod_rewrite, 
and mod_ssl from my server config and I still got the error in my tests.

I also tried varying the mod_deflate config (as you pointed out it was 
redundant/wrong)...

Also Bill, why do you have this setup:

Location /perl
  AddOutputFilterByType DEFLATE text/*
  SetOutputFilter DEFLATE
/Location
why adding it twice? You need only the latter inside Location, or 
alternatively only the former outside Location if you want it to be 
set globally:
http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype
Ah, I misunderstood the mod_deflate docs.  I think at the time, it didn't 
seem to work with just one of them in-place, so I added the 
other.  *SHRUG*  I can't say I'm a pro at Apache config files, I just 
tinker until it works.  I assume this is irrelevant to the bug, though.
I'm not sure if your config doesn't insert the filter twice. Need to check 
whether SetOutputFilter overrides AddOutputFilterByType as well.
In my config, I have a deflate log:

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i' 
deflate
CustomLog /var/log/httpd/deflate_log deflate

I was using this to verify that deflate was active or not.  What I found 
was that using AddOutputFilterByType DEFLATE text/* doesn't seem to 
activate deflate, no matter where I put it (in a Location or at the 
top-level of the config).  My deflate log shows that no compression is 
occurring.  SetOutputFilter DEFLATE does activate deflate globally (for 
all locations), no matter where I put it.  I'm afraid I don't find the 
mod_deflate docs very clear on placement.

When you were trying to reproduce, I don't know if you used my (redundant) 
config before, but if you only used AddOutputFilterByType DEFLATE text/*, 
and not SetOutputFilter DEFLATE, that might explain why you were not able 
to reproduce this, I don't think that activates deflate (at least that's 
what my deflate_log shows for me).

Otherwise, if you're still not reproducing this, I would assume there's 
some difference in the way we are building apache or our apache config 
files or perl?

Here's my Apache Configure line:

./configure --enable-modules=all --enable-mods-shared=all --enable-deflate 
--with-mpm=prefork --enable-rewrite --enable-ssl

Here are the Modules I load:

LoadModule cgi_module modules/mod_cgi.so

LoadModule access_module modules/mod_access.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule perl_module modules/mod_perl.so
LoadModule ssl_module modules/mod_ssl.so
mod_cgi, mod_ssl and mod_rewrite seem to be innocent (when I removed them, 
it still failed), but maybe you're using a module that I'm not and this is 
causing your config to work better?   I think that I'm loading less modules 
than what is typical, I removed as many as I could to reduce memory usage a 
while ago.

*SHRUG*

One thing that may be relevant is tracking down where the 20014:Error is 
coming from.  Web searching seems to associate it with Berkeley DB code, 
which seems odd to me, is Apache using Berkeley DB code somewhere (via a 
filter?)?

This isn't a very important issue for me.  I have a decent workaround 
(print   instead of ), plus I'm not really able to use mod_deflate that 
much anyway because it puts too much load on my server (mod_gzip with 
Apache 1.3 worked better for me).

Thanks

-bill

modperl2 Apache::HTTP_FORBIDDEN and Apache::HTTP_INTERNAL_SERVER_ERRORimplemented?

2003-07-15 Thread speeves

Hi!

Just wondering if Apache::HTTP_FORBIDDEN and 
Apache::HTTP_INTERNAL_SERVER_ERROR have been implemented?  I have been 
trying to port Apache::AuthenNTLM, and keep getting:

[Tue Jul 15 16:46:08 2003] [error] failed to resolve handler 
`Apache::AuthenNTLM'
[Tue Jul 15 16:46:08 2003] [error] [client 192.168.1.2] Bareword 
Apache::HTTP_FORBIDDEN not allowed while strict subs in u
se at /usr/local/lib/perl/5.6.1/Apache/AuthenNTLM.pm line 593.
Bareword Apache::HTTP_INTERNAL_SERVER_ERROR not allowed while strict 
subs in use at /usr/local/lib/perl/5.6.1/Apache/Authe
nNTLM.pm line 597.
Bareword Apache::HTTP_INTERNAL_SERVER_ERROR not allowed while strict 
subs in use at /usr/local/lib/perl/5.6.1/Apache/Authe
nNTLM.pm line 632.
BEGIN not safe after errors--compilation aborted at 
/usr/local/lib/perl/5.6.1/Apache/AuthenNTLM.pm line 671.
Compilation failed in require at (eval 10) line 3.

in the error_log.  I have other constants that are imported from 
Apache::Const, so do not think that it is a problem with scope...  Here 
is the code:

line 593 --  return $self-{ntlmauthoritative} ? (defined($nonce) ? (MP2 
? Apache::HTTP_FORBIDDEN : Apache::Constants::HTTP_
FORBIDDEN) : (MP2 ? Apache::HTTP_INTERNAL_SERVER_ERROR : 
Apache::Constants::HTTP_INTERNAL_SERVER_ERROR)) : (MP2 ? Apache::DE
CLINED : Apache::Constants::DECLINED) ;

and

line 632 --- # return MP2 ? Apache::HTTP_INTERNAL_SERVER_ERROR : 
Apache::Constants::HTTP_INTERNAL_SERVER_ERROR ;

If you need more, let me know.

thanks,
speeves
cws

Re: mod_perl 1.0 and 2.0

Chris Faust wrote:

There is a 0.92 version of Apache::DBI is mp2 aware (there may even be 
a later version at this point).
We started with mp1 and do to problems we decided to goto mp2 (which 
turned out to be non mod_perl and apache related), there wasn't any 
major performance increase or anything like that and I don't remember 
anything major coming up during the switch (outside of cookies - which 
always seem to be a problem).
I use a bunch of the popular modules like HTML::Template, 
Image::Magick, DBI, Parse/WriteExcel, Date::Manip etc and I haven't 
had any problems.
Like Sreeji said, its really about your requirements - but the above 
is my experience, for what its worth.
-Chris

- Original Message -
*From:* Jamie Krasnoo mailto:[EMAIL PROTECTED]
*To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, July 09, 2003 3:49 PM
*Subject:* mod_perl 1.0 and 2.0
Hi all,

Im currently working on a personal project to get myself back in
mod_perl programming order. However Im more used to using
mod_perl 1.0 with Apache 1.3.x. Im going through the
documentation for mod_perl 2.0 but Im worried that most of the
modules I need wont work with mod_perl 2.0. Ive been looking for
what modules will and will not work with 2.0 (like Apache::DBI for
pooling connections with MySQL). Would it be a better benefit to
me to switch over to 2.0?
Thanks,

Jamie

We need more help in porting more mods to go with mp2... too ;) Come 
join the fray :)

speeves
cws

Re: AuthenNTLM - Help

Stas Bekman wrote:

Francisco de Assis Tristão wrote:

Frank,
please, i am trying to configure AuthenNTLM on a solaris 2.8 (SPARC)
machine. But i did not find any sample about how to configure
httpd.conf. May you help me? I had compiled apache 2 version 2.0.46 with
ssl suport (i am configuring it with mod_jk and Tomcat too). Do i need
to have mod_perl installed?


You certainly need to have mod_perl installed. This and other 
questions are answered at http://perl.apache.org/.

However I'm not sure whether this module has been ported to mod_perl 
2.0. Therefore you probably need to either port it, or use mod_perl 
1.0, in case it wasn't ported yet.



__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
I am in the process of porting it now.  Will hopefully have a working 
version in the next couple of days. 

Francisco, check out the documentation using perldoc:

perldoc Apache::AuthenNTLM

There is an example for the httpd.conf configuration in there.

I'll keep you posted on the port, and will announce when and where I 
have a working version.  The author is only excepting patches for the 
mod, so will probably take a little time for him to get my changes 
implemented into the indexed version.  (Will also keep you posted on 
that... :) )

speeves
cws

Re: informational notice in Makefile.PL

2003-07-15 Thread Randy Kobes

On Tue, 15 Jul 2003, Shannon Eric Peevey wrote:

 Here is an example of my Makefile.PL using ModUtils::AutoInstall:
[ ... ]
 I then add the necessary code inside of the .pm file to check
 the version of mod_perl on the machine and perform
 appropriately. (I hope... ;) )  This allows a module to live in
 both worlds, and removes the necessity of supporting two code
 bases.  I think that this type of porting will help authors to
 go ahead and port their modules, expanding the mp2 module base,
 and alleviate fears of jumping off of a cliff and leaving mp1
 behind.

ExtUtils::AutoInstall is pretty powerful, and flexible. It does
though add an extra external dependency that the end user must
normally install. For some packages (eg, those supplying custom
config directives that must 'use mod_perl;' right within
Makefile.PL to build), this is probably the easiest approach. For
other, less complicated dependencies, though, that still need
something extra beyond the standard ExtUtils::MakeMaker and
friends, Module::Install might be a simpler approach - there's
nothing extra that the user has to install, as the code for any
additional functionality is included within the distribution.

-- 
best regards,
randy

Re: Virtual Host Logging Perl Script