Apache::Registry HEAD fix
Hi mod_perl Geeks, A few weeks ago I raised the issue of Apache::Registry issuing incorrect headers in the case of a HEAD request, as it's also returning the headers. Geoffrey Young came up with a subclass of Apache::RegistryNG, and I forgot everything about it until yesterday, when I realized that it was working with none of my scripts :-/ Anyway as promised, (late, but...) here is something that seems to work OK and that's not _too_ hackish. Please take some time to test it, and maybe change the module name :-) Tell me what you think! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM Registry.pm Description: Perl program
Re: Apache::Registry HEAD fix
Jean-Michel Hiver wrote: Hi mod_perl Geeks, A few weeks ago I raised the issue of Apache::Registry issuing incorrect headers in the case of a HEAD request, as it's also returning the headers. Geoffrey Young came up with a subclass of Apache::RegistryNG, and I forgot everything about it until yesterday, when I realized that it was working with none of my scripts :-/ hmph. what about it wasn't working? I mean, I tested it with some plain CGI.pm scripts, and it seemed to work fine. do you have any more information? perhaps a sample script I can test it with? --Geoff
Re: Apache::Registry HEAD fix
I tried it with the product I'm working on and it just kept outputting blank body data. hmph. very odd. I guess we need to trace the output to see what's going on. Yep. Lots of wierdness... The only thing I can assure is that the script works fine under mod_cgi, and is messing with Apache objects at all. I am now using a very simple script and I have realized that my solution does not work in all cases either :-) yes, that's what I pointed out before :) http://marc.theaimsgroup.com/?l=apache-modperlm=100687034903369w=2 Wow, that's different now. I'm not redirecting to /dev/null but to a temp file from which I extract the headers. ok. in true programmer fashion, of course I think my approach is better :) at least, it seems less hackish to me, and playing with STDOUT just isn't typical in mod_perl, since it's really tied behind the scenes. Well actually I tend to agree with that. I don't really like the fact that I need to create temp files, nor redirect STDOUT. But hey, I'm just trying to get this stuff working OK... and I can't find any decent online API reference for Apache::RegistryNG. Besides, the edition of Writing Apache modules with Perl and C that I'm using doesn't seem to cover all Apache::Registry API. Sigh... anyway, if you send me a sample script I can play with it some. for the most part, my stuff is code ripped right from mod_perl core, but there could be something subtle going on that is easily fixable. Okay dokay. I'll stop playing with my mailer and try to do some debugging work now :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
RE: Cache::FileCache issues
Hrm. I'm running Solaris 8 with a standard install/patch set. I've tried manipulating the path to have mkdir either be the solaris default (/usr/bin/mkdir) or the GNU fileutils version (/opt/gnu/bin/mkdir). Both produce the same error. [Tue Jan 29 08:28:43 2002] [debug] AuthenCache.pm(197): [client 1.16.67.28] manage_cache: path=/opt/gnu/bin:/sbin:/usr/sbin:/usr/bin [Tue Jan 29 08:28:43 2002] [debug] AuthenCache.pm(200): [client 1.16.67.28] manage_cache: mkdir=/opt/gnu/bin/mkdir [Tue Jan 29 08:28:43 2002] [error] mkdir : No such file or directory at /opt/gnu/depot/perl-5.6.1/lib/site_perl/5.6.1/Cache/FileBackend.pm line 220 [Tue Jan 29 08:32:13 2002] [debug] AuthenCache.pm(197): [client 1.16.67.28] manage_cache: path=/usr/bin:/opt/gnu/bin:/sbin:/usr/sbin [Tue Jan 29 08:32:13 2002] [debug] AuthenCache.pm(200): [client 1.16.67.28] manage_cache: mkdir=/usr/bin/mkdir [Tue Jan 29 08:32:13 2002] [error] mkdir : No such file or directory at /opt/gnu/depot/perl-5.6.1/lib/site_perl/5.6.1/Cache/FileBackend.pm line 220 Regards, Christian -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 4:38 PM To: Christian Gilmore; Modperl Mailing List (E-mail) Subject: Re: Cache::FileCache issues [Mon Jan 28 14:52:35 2002] [error] mkdir : No such file or directory at /opt/gnu /depot/perl-5.6.1/lib/site_perl/5.6.1/Cache/FileBackend.pm line 220 Looks to me like your system has no mkdir command, or it isn't in the path, or it doesn't support an option that's needed (-p maybe?). Maybe Cache::FileBackend should use File::Path::mkpath for portability. - Perrin
Re: Dynamically serving an .htaccess file with mod_perl
Michael A Nachbaur [EMAIL PROTECTED] said something to this effect on 01/28/2002: Does anyone know of a way that I can server the contents of an .htaccess file dynamically? I know Apache checks the request directory (and all directories above it) for an .htaccess file before serving a file request, but there is no mention of how it goes about loading that file. Make the .htacess file in question a FIFO, with a script on the backend that Does The Right Thing. (darren) -- Unix is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a boot partition virus. -- Peter H. Coffin
Re: Dynamically serving an .htaccess file with mod_perl
Does anyone know of a way that I can server the contents of an .htaccess file dynamically? Make the .htacess file in question a FIFO, with a script on the backend that Does The Right Thing. Whoops, you would loose big when two concurrent Apache processes attempt to access the .htaccess simultaneously... Why not rewrite AuthenHandler instead (we are on mod_perl list right ?) -- Dominique QUATRAVAUX Ingénieur développeur sénior 01 44 42 00 35 IDEALX
New mod_perl Logo
As many of you are aware, a new mod_perl website is currently being developed and is near to going live. To accompany the new site, and with mod_perl 2.0 development well under way, I have initiated a competition to find a new mod_perl logo. Therefore, I am asking any budding artists/designers amongst you to submit your efforts to myself ([EMAIL PROTECTED]). I will make all submissions available for public review on the web at: http://wypug.digital-word.com/mod_perl/ (where a few designs are even now awaiting your perusal). Once I have accumulated enough variety, I will run a voting booth so that the winning design can be democratically chosen. The reward for your efforts: Eternal fame and fortune, glamour, admiration, kudos, etc... Well, at the very least, you will get the pleasure of seeing your design every time you visit the mod_perl website. It also possible that you would be credited by name/alias within the site. So come on folks, fire up the GIMP/PhotoShop and get to work. There are no rules, no preconceived ideas and no restrictions. You can use the exisiting icons of mod_perl (the camel, Apache feather, eagle, etc), or go for something entirely new - it's up to you. Ideas for logos, banners, powered by-type buttons are all welcome. Please don't send submissions to the mailing list(s) - send them directly to me ([EMAIL PROTECTED]). May the best man win. :-) Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ NOTE: The WYPUG webserver is not very stable at the moment. If the site is unavailable, then please try again a little later. We're working on a solution right now...
Re: Dynamically serving an .htaccess file with mod_perl
[EMAIL PROTECTED] writes: Does anyone know of a way that I can server the contents of an .htaccess file dynamically? Make the .htacess file in question a FIFO, with a script on the backend that Does The Right Thing. Whoops, you would loose big when two concurrent Apache processes attempt to access the .htaccess simultaneously... Not if the file is small enough...low level reads are granular up to, I think 8k. Maybe. -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Interim Technical Director, Web Architecture Consultant for hire
Re: Apache::args vs Apache::Request speed
John Siracusa [EMAIL PROTECTED] writes: I'm cc-ing this to the Mac OS X Perl list in the hopes that someone can provide a test environment for you. (I would, but my OS X box is behind a firewall at work.) So how about it, [EMAIL PROTECTED] folks, can any of you help get libapreq up and running on OS X an long last? (See message quoted below) Maybe this will help: http://fink.sourceforge.net/doc/porting/porting.html The Unix build of libapreq goes in 3 steps: 1) build a static c library: libapreq.a 2) build object files Request.o, Cookie.o 3) link each object file against libapreq.a to make shared libraries Request.so Cookie.so So each file gets it's own copy of libapreq, symbols and all. For ELF-based systems, that's not a problem since the linking executable knows not only the library's filename, but also the location of the desired symbol within the file (actually there's something called a jump table inside the .so that provides some necessary indirection, but that's a technicality that's not particularly relevant to the issue.) AIUI, the problem with OS/X is that their linker doesn't provide the executable with a similar addressing scheme for unresolved symbols; it just tells the executable which libraries are needed to resolve them without also telling it where to look for a given symbol. So because Request.bundle and Cookie.bundle both (accidentally?) provide resolution for libapreq's symbols, the executable gets confused and bails out. If I'm right here, then removing the libapreq symbols from Cookie.bundle and Request.bundle should do the trick. There are lots of ways to reorganize things in order to achieve this, and I'm somewhat surprised that none of the OS/X folks have made any progress in this regard. So maybe I'm wrong, but I don't think any of us will learn the answer until some OS/X person actually _attempts_ to fix it. -- Joe Schaefer
Re: New mod_perl Logo
On Tuesday 29 January 2002 19:10, Markus Wichitill wrote: exisiting icons of mod_perl (the camel, Apache feather, eagle, etc), or Please let's not choose one with an ORA animal as the official logo. It's very annoying having to include those stupid copyright notices just because the logo is used on a page. Note that that makes the only forbidden animal a white-tailed eagle I guess. Any other animal should be ok. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Make it idiot proof and someone will make a better idiot.
RE: New mod_perl Logo
:: Please let's not choose one with an ORA animal as the :: official logo. It's very annoying having to include those :: stupid copyright notices just because the logo is used on a page. The final logo will be chosen by majority vote. :: And since I've now posted to the list anyway, I can as well :: link my powered-by-button entry, which is partly based on a :: previous mod_perl site redesign that was never used in the :: end (sorry, forgot by whom it was): :: http://www.mawic.de/modperl.gif I have added your button to the gallery, thank you Markus. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: New mod_perl Logo
Note that that makes the only forbidden animal a white-tailed eagle I guess. Any other animal should be ok. The context is Apache and Perl, so wouldn't that include eagle, camel, llama and whatever other book animals I've missed?
Re: ANNOUNCE: HTTP::TestEngine v0.02
On Tue, 29 Jan 2002, Chris Brooks wrote: I have released version 0.02 of HTTP::TestEngine to sourceforge. TestEngine acts as an http session recorder. After setting a cookie, a user can record a session by simply clicking links in their browser: filenames, paths and parameters are written to the filesystem for recall in the future. Session data is stored in test harness-independent format, and a second module, HTTP::SessionConfig is responsible for converting the session data into a data structure that is appropriate for play-back. HTTP::Monkeywrench is currently supported, with plans for HTTP::WebTest support in the future. This is funny. I was working on something very similar recently. It was designed to be able to work with both vanilla CGI and mod_perl (via Apache::Filter). It's more cross-platform that your current code and also records a lot more info. Maybe we can work together to integrate our code. We can probably talk more off the list. -dave /*== www.urth.org we await the New Sun ==*/
Re: ANNOUNCE: HTTP::TestEngine v0.02
On Tue, 29 Jan 2002 13:03:56 -0600 (CST), Dave Rolsky [EMAIL PROTECTED] said: DR On Tue, 29 Jan 2002, Chris Brooks wrote: I have released version 0.02 of HTTP::TestEngine to sourceforge. TestEngine acts as an http session recorder. After setting a cookie, a user can record a session by simply clicking links in their browser: filenames, paths and parameters are written to the filesystem for recall in the future. Session data is stored in test harness-independent format, and a second module, HTTP::SessionConfig is responsible for converting the session data into a data structure that is appropriate for play-back. HTTP::Monkeywrench is currently supported, with plans for HTTP::WebTest support in the future. DR This is funny. I was working on something very similar recently. It was DR designed to be able to work with both vanilla CGI and mod_perl (via DR Apache::Filter). It's more cross-platform that your current code and also DR records a lot more info. Maybe we can work together to integrate our DR code. We can probably talk more off the list. I quite interested in this project also (as maintainer of HTTP::WebTest :). Something like HTTP::TestEngine which can record tests for HTTP::WebTest was in my TODO for a long time. I just had no time for it ;( -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) | | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: New mod_perl Logo
exisiting icons of mod_perl (the camel, Apache feather, eagle, etc), or Please let's not choose one with an ORA animal as the official logo. It's Well, seeing as this would be the new version of mod_perl, I could see it being worth ORA's while to forgo their little copyright nonsense. I'm sure, if a really nice design comes up with the mod_perl eagle, that ORA wouldn't mind bending their copyright for us. After all, its extra publicity for them, right? -man
Re: New mod_perl Logo
On Tue, 29 Jan 2002, Michael A Nachbaur wrote:
Well, seeing as this would be the new version of mod_perl, I could see it
being worth ORA's while to forgo their little copyright nonsense. I'm sure,
if a really nice design comes up with the mod_perl eagle, that ORA wouldn't
mind bending their copyright for us. After all, its extra publicity for
them, right?
That's not how trademarks work. ORA have to complain about every use of
a trademarked form that comes to their attention, otherwise the trademark
lapses.
If their trademark lapses, then someone else can produce Eagle books.
To borrow the really horrible slashdot phrase though, I am not a lawyer
Later.
Mark
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}
problems with DirectoryIndex under mod_perl + Template Toolkit
I'm using mod_perl + Template Toolkit, and I'm having trouble getting Apache
to pass the DirectoryIndex to my handler. The handler is supposed to take
the path_info and pull a template of the same name from a subdirectory
called 'html'.
This works fine for file names which do exist in the subdirectory. And, if
they don't exist, an error is correctly generated. However, if the path is
empty or '/', I expect Apache to include the DirectoryIndex (index.html) in
path_info or somewhere else that I can get to it. Unfortunately, Apache is
passing empty paths and '/' straight through to the handler, causing a file
not found error.
Maybe I'm just not looking in the right place, but I've spent a lot of time
Googling and looking at the mod_perl guide, and I can't seem to find an
exact answer to my problem. This would seem to be a common issue. Can anyone
offer a solution?
Admittedly, I'm new to Apache, mod_perl and Template Toolkit, and I'm
getting my feet wet trying to learn all three using my Windows 2000
workstation as a test bed, although the eventual target server will be
running Linux. Below is some sample code (mostly copied/modified from
various online sources) that I boiled down in an attempt to solve the
problem, but to no avail.
Thanks in advance.
-Tim
httpd.conf
--
# default win32 config up to here ...
# mod_perl config
Include conf/perl.conf
--
perl.conf
-
LoadModule perl_module modules/mod_perl.so
AddModule mod_perl.c
PerlRequire conf/startup.pl
PerlWarn On
PerlTaintCheck On
PerlFreshRestart On
PerlSetVar websrc /usr/local/apache/tt
Location /tt
SetHandler perl-script
PerlHandler Test::Mod
/Location
--
startup.pl
--
#!/usr/bin/perl -w
use strict;
BEGIN {
# modify include path
use Apache ();
use lib Apache-server_root_relative('lib/perl');
}
# are we under mod_perl?
$ENV{MOD_PERL}
or die(not running under mod_perl);
# detailed warnings
use Carp ();
$SIG{__WARN__} = \Carp::cluck;
# load common modules
use Apache::Constants ();
use Template ();
# load custom modules
use Test::Mod ();
1;
--
Test/Mod.pm
---
#!/usr/bin/perl -wT
package Test::Mod;
use strict;
use Apache::Constants qw( :common );
use Template qw( :template );
our $VERSION = 0.01;
sub handler {
my $r = shift;
my $websrc = $r-dir_config('websrc')
or return fail( $r, SERVER_ERROR, 'websrc' not specified );
my $template = Template-new({
INCLUDE_PATH = $websrc:$websrc/html:$websrc/html/include,
OUTPUT = $r,
});
# use the path_info to determine which template file to process
my $file = $r-path_info();
$file =~ s[^/][];
my $vars = {
uri = $r-uri(),
file = $r-filename(),
path = $r-path_info(),
tt = $file,
};
$r-content_type('text/html');
$r-no_cache(1);
$r-send_http_header();
$template-process($file, $vars)
or return fail( $r, SERVER_ERROR, $template-error() );
return OK;
}
sub fail {
my ($r, $status, $message) = @_;
$r-log_reason( $message, $r-filename() );
return $status;
}
--
index.html
--
[% PROCESS header.html
title = 'template test'
%]
puri: [% uri %]/p
pfile: [% file %]/p
ppath: [% path %]/p
ptemplate: [% tt %]/p
[% PROCESS footer.html %]
can not set param
Folks,
The apache::Request docs indicate that param can be used to set the
query string. However,
it fails when I do something like this:
my $r = Apache::Request-new(shift);
...
my $host= $r-hostname;
my $uri = $r-uri;
my $params = $r-parsed_uri-query;
# does not seem to work!?
my $scheme = $r-parsed_uri-scheme || 'https';
$r-param('previous_uri' = $scheme://$host$uri);
$r-param('q_string' = $params) if ($params);
$r-header_out(Location = http://$host/login;);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
Can someone tell me why this is failing? I can not get previous_uri or
q_string in my login module.
Also, $r-parsed_uri-scheme does not return anything back.
Thanks in advance.
-r
Re: can not set param
Rasoul Hajikhani wrote:
Folks,
The apache::Request docs indicate that param can be used to set the
query string. However,
it fails when I do something like this:
my $r = Apache::Request-new(shift);
...
my $host= $r-hostname;
my $uri = $r-uri;
my $params = $r-parsed_uri-query;
# does not seem to work!?
my $scheme = $r-parsed_uri-scheme || 'https';
$r-param('previous_uri' = $scheme://$host$uri);
$r-param('q_string' = $params) if ($params);
$r-header_out(Location = http://$host/login;);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
Can someone tell me why this is failing? I can not get previous_uri or
q_string in my login module.
Also, $r-parsed_uri-scheme does not return anything back.
Thanks in advance.
-r
why not use $r-args ??
my %args = $r-args;
then just have to call your queries like
$args{Members_id_ext}
Re: New mod_perl Logo
On Tue, 29 Jan 2002, Jonathan M. Hollin wrote: Ideas for logos, banners, powered by-type buttons are all welcome. Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. For any number of reasons, perl does now and will always face an uphill struggle in any Enterprise application. For example, at my place of employment, we just went through a rather arduous task that I fought against and lost. We had a production site that handled a decent amount of traffic. Apache, mod_perl, Linux and MySQL. It ran and ran with almost no intervention. The management team of the company that bought us a year ago had been trying to force a change in the product by throwing up various arguments, which were always false. (MySQL doesnt support Transaction, Yes it does. But they arent atomic., Yes they are. Well, you can't roll them back., Yes you can.) In the end, I lost. From October to mid January they set about taking our fully functional product and replatforming it to Win2k/IIS/ASP+VB/MSSQL. The final reason? Responsible enterprises do not use perl. mod_perl needs a name. Something marketable, something catchy. The java folks learned that a long time ago. Their systems are called Tomcat/Jakarta and Cocoon and Resin. THAT, in my opinion, is what should happen for mod_perl 2.0. It should be Adirondack or Orwell or any other generic, innocuous name. Even MonkeyButter v1.0 is probably a better deal than mod_perl. As for logos, Avoiding Camels or Eagles is a requirement. I don't blame ORA for requiring the trademark notices, the twisted concepts of US trademark law REQUIRE them to do that. The first time they didnt, they could lose their trademark. But we should have a mascot that makes sense and is OURS. Linux has the penguin, OpenBSD has the blowfish, the other BSD's have the devil. Those images are clearly associated with those products, and can be used WITHOUT corporate approval. -- ___ Chris Thompson
Re: New mod_perl Logo
I could not agree more. I can not compute how much of my time would have been saved over the last few years had I been able to say something like 'We are using the Orwellian AppSphere 2002 running on Apache' to VC's and management rather then 'Mod Perl'. Perception counts I am affectionate towards the mod_perl name after so many years but its really not optimal. John- On Tuesday, January 29, 2002, at 04:29 PM, Chris Thompson wrote: On Tue, 29 Jan 2002, Jonathan M. Hollin wrote: Ideas for logos, banners, powered by-type buttons are all welcome. Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. For any number of reasons, perl does now and will always face an uphill struggle in any Enterprise application.
Re: New mod_perl Logo
Hi ct ! On Wednesday 30 January 2002 01:29, Chris Thompson wrote: Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. This discussion has occured already. The conclusion was simple: the name won't change. Doug cut the talk saying that he won't change the name, and I must say I agree. That isn't to say your points are invalid, you're concern is justified. The solution here is not to change modperl's name. modperl, in a way, is a low level thing. It's just Perl + Apache. When in need of a convincing name, say I use Foo where Foo is the name of something that runs on top of modperl. I use AxKit, I use FooAppFramework, etc. can sound a lot better. Of course, on top of that you need a good looking website with marketing talk. In any case changing the name alone doesn't help. Website content welcome ;-) -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Paranoids are people, too; they have their own problems. It's easy to criticize, but if everybody hated you, you'd be paranoid too.
Re: can not set param
Geoffrey Young wrote:
Rasoul Hajikhani wrote:
Folks,
The apache::Request docs indicate that param can be used to set the
query string. However,
it fails when I do something like this:
my $r = Apache::Request-new(shift);
...
my $host= $r-hostname;
my $uri = $r-uri;
my $params = $r-parsed_uri-query;
# does not seem to work!?
my $scheme = $r-parsed_uri-scheme || 'https';
$r-param('previous_uri' = $scheme://$host$uri);
$r-param('q_string' = $params) if ($params);
$r-header_out(Location = http://$host/login;);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
Can someone tell me why this is failing? I can not get previous_uri or
q_string in my login module.
the way you are thinking about it is fundamentally wrong - $r is the
_current_ request object, so setting $r-param sets query string
arguments for the current request only.
you need to look into the Apache::URI module, which can be used to
create
unless ($c-{userId} $c-{user})
{
my $p_uri = $r-parsed_uri;
my $string = previous_uri= . $r-uri .
($r-args() ? ? . $r-args() : undef);
$p_uri-query($string);
return FORBIDDEN;
}
This still fails to resolve the problem. Unless ofcourse I am not using
the right method.
-r
properly formed URI strings.
Also, $r-parsed_uri-scheme does not return anything back.
it won't - to create a self-referential URI use Apache::URI-parse($r)
HTH
--Geoff
New mod_perl name was [Re: New mod_perl Logo]
how about Everest? Niagara? Multiphase? Slipstream? DigiServer? Pointillion? Web Mammoth? SharpWeb? Web Enterprise? EnterWeb? Ged Haywood wrote: Hi there, On Tue, 29 Jan 2002, Chris Thompson wrote: mod_perl is a lousy name. [snip] mod_perl needs a name. Something marketable, something catchy. How about BigFoot? 73, Ged. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: New mod_perl Logo
Thanks for sharing your opinion and it has brought up some of my own that I had held in reserve for sometime now. I would 100% agree with a claim that a name is effecting usage if we were selling a food product or something else to the general public, but even then far more products have failed because they weren't properly explained to the public. mod_perl is a beast of tool/product. It harnesses the full power of Apache web server and Perl to allow you do dam near anything with the data you need to handle. Apache because of its large platform support and well designed architecture has proven that it is enterprise ready. That brings me to the rub of this discussion however, Perl. I love Perl, I use Perl for almost every programming task that I need in my work and personal computing use. That isn't enough though. Perl has a rep, MySQL has a rep too. These *once* true statements such as Its just a scripting language for Unix or It doesn't support transactions etc. are becoming more and more the cripples of the acceptance not the name. These great and power products don't have someone dispelling the myths on national television while none computer managers are watching TV, they only remember what the last consultant said. I am not knocking managers I am just showing human nature, that is we don't change our opinions unless someone we trust (the TV? ) more then the last person explains clearly why we should. We have had several discussions over the last three years on this list about advocating mod_perl. I think what it really boils down to is a polished web presence and a strong statement of the power and efficiency of the product at hand and in this case a place your favorite open source application here page to refute known myths. Aaron Johnson Chris Thompson wrote: On Tue, 29 Jan 2002, Jonathan M. Hollin wrote: Ideas for logos, banners, powered by-type buttons are all welcome. Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. For any number of reasons, perl does now and will always face an uphill struggle in any Enterprise application. For example, at my place of employment, we just went through a rather arduous task that I fought against and lost. We had a production site that handled a decent amount of traffic. Apache, mod_perl, Linux and MySQL. It ran and ran with almost no intervention. The management team of the company that bought us a year ago had been trying to force a change in the product by throwing up various arguments, which were always false. (MySQL doesnt support Transaction, Yes it does. But they arent atomic., Yes they are. Well, you can't roll them back., Yes you can.) In the end, I lost. From October to mid January they set about taking our fully functional product and replatforming it to Win2k/IIS/ASP+VB/MSSQL. The final reason? Responsible enterprises do not use perl. mod_perl needs a name. Something marketable, something catchy. The java folks learned that a long time ago. Their systems are called Tomcat/Jakarta and Cocoon and Resin. THAT, in my opinion, is what should happen for mod_perl 2.0. It should be Adirondack or Orwell or any other generic, innocuous name. Even MonkeyButter v1.0 is probably a better deal than mod_perl. As for logos, Avoiding Camels or Eagles is a requirement. I don't blame ORA for requiring the trademark notices, the twisted concepts of US trademark law REQUIRE them to do that. The first time they didnt, they could lose their trademark. But we should have a mascot that makes sense and is OURS. Linux has the penguin, OpenBSD has the blowfish, the other BSD's have the devil. Those images are clearly associated with those products, and can be used WITHOUT corporate approval. -- ___ Chris Thompson
Re: New mod_perl Logo
In a message dated 30-Jan-02 12:50:50 AM GMT Standard Time, [EMAIL PROTECTED] writes: How about "BigFoot"? Probably not the best for a server application. Might make one think of the "footprint" involved ... and isn't one of the major reasons to moving to mod_perl to reduce the overhead and "footprint" of the server? Now Yetti no conotation there. Or Swamp Beast, Sasquatch, or possibly even the local favorite Nessie (I'd love to see Ora get a picture of her on the next book!) -Chris
Re: New mod_perl Logo
I agree. mod_perl is a technology not a platform. Java is called Java, Servlets are called Servlets, but products on top of the technology (eg app servers) are usually have the name Orwellian Pearlz Factory. If you wanted to use a marketing name, you should have just told them you were using one of the frameworks on top of mod_perl like AxKit or Mason. At 08:59 AM 1/30/2002, Robin Berjon wrote: Hi ct ! On Wednesday 30 January 2002 01:29, Chris Thompson wrote: Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. This discussion has occured already. The conclusion was simple: the name won't change. Doug cut the talk saying that he won't change the name, and I must say I agree. That isn't to say your points are invalid, you're concern is justified. The solution here is not to change modperl's name. modperl, in a way, is a low level thing. It's just Perl + Apache. When in need of a convincing name, say I use Foo where Foo is the name of something that runs on top of modperl. I use AxKit, I use FooAppFramework, etc. can sound a lot better. Of course, on top of that you need a good looking website with marketing talk. In any case changing the name alone doesn't help. Website content welcome ;-) -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Paranoids are people, too; they have their own problems. It's easy to criticize, but if everybody hated you, you'd be paranoid too. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
[BUG] mod_perl confused about method calls when using internal_redirect
I've found that mod_perl can get confused when dealing with method
calls during a redirect_internal phase:
1. page /1 uses method calls, and works when accessed as /1
2. an other page /R uses internal_redirect to go to /1, and mod_perl
fails with an undefined subroutine error.
This has been seen on:
apache 1.3.9-14, perl 5.004.05-1.1, and mod_perl 1.25-3 (Debian potato)
and on:
apache 1.3.22-2.1, perl 5.6.1-6, and mod_perl 1.26-1 (Debian woody/testing)
How to reproduce:
Use this startup.pl file:
==
# Common
package Common;
use Apache::Constants qw(:common);
sub handler($$)
{
my $self = shift;
my $req = shift;
$req-content_type('text/plain');
$req-send_http_header();
$req-print($self-doit());
return OK;
}
sub doit
{
return COMMON;
}
# Common::Impl1
package Common::Impl1;
@ISA=qw(Common);
sub doit
{
return IMPL1\n;
}
# Common::Impl2;
package Common::Impl2;
@ISA=qw(Common);
sub doit
{
return IMPL2\n;
}
# Redir
package Redir;
use Apache::Constants qw(:common);
sub handler
{
my $req = shift;
$req-internal_redirect(/1);
return OK;
}
1;
==
PerlRequire the above, and use the following apache configuration:
==
Location /0
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common
/Location
Location /1
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common::Impl1
/Location
Location /2
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Common::Impl2
/Location
Location /R
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Redir
/Location
PerlRequire startup.pl
==
Then, directing a web browser to /0 prints COMMON, to /1 prints IMPL1,
to /2 prints IMPL2, as expectected.
Similarly, when pointing to /R (which redirects internally to /1),
IMPL1 should appear.
However, I get a 500 Internal server error and this in the logs:
[error] Undefined subroutine Common::Impl1::handler called at
startup.pl line 49.
I've tried to debug the problem, and the problem lies inside
perl_handler_ismethod() in src/modules/perl/mod_perl.c: it returns
different values when called from inside the internal_redirect than
called without internal_redirect.
Inside perl_handler_ismethod():
if(!sub) return 0;
sv = newSVpv(sub,0);
if(!(cv = sv_2cv(sv, stash, gv, FALSE))) {
GV *gvp = gv_fetchmethod(pclass, sub);
if (gvp) cv = GvCV(gvp);
sv_2cv() returns different values when called from inside an
internal_redirect than called without
internal_redirect. Unfortunately, I could not grok sv_2cv(). It's not
even documented in the perl docs.
Phil.
Re: New mod_perl Logo
I really don't think a catchy name would have helped in your case. Your management, like many others, prefer to manage by magazine. And we all know who is in all the magazines. If your management did not like Perl, why not try java, c or php? If your management did not like MySQL, why not Postgres, Sybase, Oracle, Informix? My point is it would not matter. The issue was not Perl, the real issue was that it was not a Microsoft product. - Original Message - From: Chris Thompson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 5:29 PM Subject: Re: New mod_perl Logo On Tue, 29 Jan 2002, Jonathan M. Hollin wrote: Ideas for logos, banners, powered by-type buttons are all welcome. Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. For any number of reasons, perl does now and will always face an uphill struggle in any Enterprise application. For example, at my place of employment, we just went through a rather arduous task that I fought against and lost. We had a production site that handled a decent amount of traffic. Apache, mod_perl, Linux and MySQL. It ran and ran with almost no intervention. The management team of the company that bought us a year ago had been trying to force a change in the product by throwing up various arguments, which were always false. (MySQL doesnt support Transaction, Yes it does. But they arent atomic., Yes they are. Well, you can't roll them back., Yes you can.) In the end, I lost. From October to mid January they set about taking our fully functional product and replatforming it to Win2k/IIS/ASP+VB/MSSQL. The final reason? Responsible enterprises do not use perl. mod_perl needs a name. Something marketable, something catchy. The java folks learned that a long time ago. Their systems are called Tomcat/Jakarta and Cocoon and Resin. THAT, in my opinion, is what should happen for mod_perl 2.0. It should be Adirondack or Orwell or any other generic, innocuous name. Even MonkeyButter v1.0 is probably a better deal than mod_perl. As for logos, Avoiding Camels or Eagles is a requirement. I don't blame ORA for requiring the trademark notices, the twisted concepts of US trademark law REQUIRE them to do that. The first time they didnt, they could lose their trademark. But we should have a mascot that makes sense and is OURS. Linux has the penguin, OpenBSD has the blowfish, the other BSD's have the devil. Those images are clearly associated with those products, and can be used WITHOUT corporate approval. -- ___ Chris Thompson
Re: Apache::AuthCookie not set cookie really
Location /agenda/ SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaPath /agenda PerlSetVar AgendaTemplate default.inc PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ Are you sure that last line is correct? That would send you to /agenda/login when authen_ses_key() fails, but your config below is for /LOGIN/. Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location This implies to me that you meant to have: PerlSetVar AgendaLoginScript /LOGIN/ Is this just a typo? I used Apache::Session::Counted, and know that this two modules may conflict, but when all Apache::Session::Counted staff is commented result is the same... I dont think they conflict. I've not heard any reports of that anyway. The cookie names are unique so there should be no problem there. I dont know why cookie is not set. I'd suspect something isnt right with your configuration. Have you tried turning on warn me before accepting cookies on your browser? Sometimes that helps me verify that the cookies are actually making it to the browser. What your trying to do looks to me like exactly the sort of thing AuthCookie can do. Unless I am misunderstanding your problem I dont see an AuthCookie limitation here. Please explain in more detail if I am missing the point and I will see what we can do if such a limitation does in fact exist :). Regards, Michael Schout (Apache::AuthCookie maintainer)
Re: Apache::AuthCookie not set cookie really
Location /agenda/ SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaPath /agenda PerlSetVar AgendaTemplate default.inc PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ Are you sure that last line is correct? That would send you to /agenda/login when authen_ses_key() fails, but your config below is for /LOGIN/. Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location This implies to me that you meant to have: PerlSetVar AgendaLoginScript /LOGIN/ Is this just a typo? I used Apache::Session::Counted, and know that this two modules may conflict, but when all Apache::Session::Counted staff is commented result is the same... I dont think they conflict. I've not heard any reports of that anyway. The cookie names are unique so there should be no problem there. I dont know why cookie is not set. I'd suspect something isnt right with your configuration. Have you tried turning on warn me before accepting cookies on your browser? Sometimes that helps me verify that the cookies are actually making it to the browser. What your trying to do looks to me like exactly the sort of thing AuthCookie can do. Unless I am misunderstanding your problem I dont see an AuthCookie limitation here. Please explain in more detail if I am missing the point and I will see what we can do if such a limitation does in fact exist :). Regards, Michael Schout (Apache::AuthCookie maintainer) Location /agenda/ SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaPath /agenda PerlSetVar AgendaTemplate default.inc PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . /Location Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location Problem was here - AgendaPath variable is set in /agenda.* location /LOGIN/ script, which set session key cookie header, doesn't see AgendaPath, therefore Cookie was a Apache::AuthCookieAgenda_Agenda=login:password variable path=/agenda was omitted. Explorer 6.0 doesn't set cookie without path attribute. I think, it's a good idea to make WhatEverPath required option in config. with config PerlSetVar AgendaPath /agenda Location /agenda SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . /Location Location /agendalogin/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location all works fine. Actually, as my application should be 1. simple maintained, 2. maximum count of users - 100 (employees in small software development company) 3. simultaneous login - 5-7 maximum 4. team managers work with money (project budjet, employee's payment per hour and etc) 5. good session solutions require database access while all, what I want to store in sessions, can get from the same database with no great effort I've decided to use simplest authentication module kinda Apache::DBILogin and if someone need real security - SSL. Thank you Sergey Polyakov aka BeerBong Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
Re: problems with DirectoryIndex under mod_perl + Template Toolkit
Tim Noll wrote: Tim, this question is not-related to TT, but a pure configuration issue. So in further postings about this issue please don't CC the tt list. (CC'ing only once now). I'm using mod_perl + Template Toolkit, and I'm having trouble getting Apache to pass the DirectoryIndex to my handler. The handler is supposed to take the path_info and pull a template of the same name from a subdirectory called 'html'. This works fine for file names which do exist in the subdirectory. And, if they don't exist, an error is correctly generated. However, if the path is empty or '/', I expect Apache to include the DirectoryIndex (index.html) in path_info or somewhere else that I can get to it. Unfortunately, Apache is passing empty paths and '/' straight through to the handler, causing a file not found error. Maybe I'm just not looking in the right place, but I've spent a lot of time Googling and looking at the mod_perl guide, and I can't seem to find an exact answer to my problem. This would seem to be a common issue. Can anyone offer a solution? That's the job of mod_dir to do that translation from / to /index.html. Does it run? For example you can use Apache::ShowRequest to look what handlers are running. In your case the best thing is to write a Fixup handler and do what mod_dir does in Perl (should be two lines of code). Here is a section from our book with an example of using Apache::ShowRequest: =head2 Investigating the Request Phases Imagine a situation where you have a complex server setup in which many different Perl and non-Perl handlers participate in the request processing, and one or more of these handlers misbehave. A simple example would be where one of the handlers alters the request record, which breaks the functionality of the other handler. Or some handler invoked first in for any given phase of the process and returns COK status, when it's not expected to do so, thus preventing other handlers from doing their job. You can't just add debug statements to trace the offender--there are too many handlers involved. The simplest solution is to get a trace of all registered handlers for each phase, stating whether they were invoked or not and what was the return status. Once such a trace is available, it's much easier to look only at the players who did something, thus narrowing the search path for a potential misbehaving module. The CApache::ShowRequest module shows the phases the request goes through, displaying the module participation in each phase and respond codes. The content response phase is not run, but possible modules are listed as defined. To configure it, just add this snippet to Ihttpd.conf: Location /showrequest SetHandler perl-script PerlHandler +Apache::ShowRequest /Location Now if you want to see what happens when you access some URI, just add it after I/showrequest. CApache::ShowRequest uses the CPATH_INFO to get to the URI that should be executed. So to run I/index.html with CApache::ShowRequest, issue a request to I/showrequest/index.html. For I/perl/test.pl, issue a request to I/showrequest/perl/test.pl. This module produces rather lengthy output, so we will show only one section from the report generated while requesting: I/showrequest/index.html: Running request for /index.html Request phase: post_read_request [snip] Request phase: translate_handler mod_perl DECLINED mod_setenvif undef mod_auth undef mod_access ..undef mod_alias ...DECLINED mod_userdir .DECLINED mod_actions .undef mod_imap undef mod_asis undef mod_cgi .undef mod_dir .undef mod_autoindex ...undef mod_include .undef mod_info undef mod_status ..undef mod_negotiation .undef mod_mime undef mod_log_config ..undef mod_env .undef http_core ...OK Request phase: header_parser [snip] Request phase: access_checker [snip] Request phase: check_user_id [snip] Request phase: auth_checker [snip] Request phase: type_checker [snip] Request phase: fixer_upper [snip] Request phase: response handler (type: text/html) mod_actions .defined mod_include .defined http_core ...defined Request phase: logger [snip] For each stage, we get a report of what modules could participate in the processing and whether they have taken any action. As you can see, the content response phase is not run, but possible modules are listed as defined. If we run a mod_perl script, the response phase looks
Re: New mod_perl Logo
Jeezus you guys. All theseAmerican-style names are verging on the racist. This is world-wide code, not f---ing American-wide code. CheersRon Savage[EMAIL PROTECTED]http://savage.net.au/index.html - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 30, 2002 12:48 PM Subject: Re: New mod_perl Logo In a message dated 30-Jan-02 12:50:50 AM GMT Standard Time, [EMAIL PROTECTED] writes: How about "BigFoot"? Probably not the best for a server application. Might make one think of the "footprint" involved ... and isn't one of the major reasons to moving to mod_perl to reduce the overhead and "footprint" of the server? Now Yetti no conotation there. Or Swamp Beast, Sasquatch, or possibly even the local favorite Nessie (I'd love to see Ora get a picture of her on the next book!) -Chris
Re: New mod_perl Logo
At 07:29 PM 01/29/02 -0500, Chris Thompson wrote: Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. I don't know about lousy, but I do agree. I brought this up on the docs-dev list: http://search.apache.org/archives/docs-dev/0236.html During the week I posted that I had run into PHP programmers at a computer show, more PHP programmers at a pub (2 in the afternoon -- more out of work programmers), and ended up talking with a couple of Java programmers one day. The amazing thing was they all had a completely weird idea about what mod_perl is or what it does. And all thought it was slow, old, dead, not scalable, technology. And that was from programmers, not managers. We all know there is a lot of misinformation out there. Marketing is not everything, but it's a lot! What we know of mod_perl is more than just perl+Apache, really. It's a development platform, or development suite. It can be anything our marketing department says it is. ;) In these tough economic times, repackaging might be helpful. Who knows? And for some of us we know that mod_perl is also something that makes up a chunk of our livelihood. So, the promotion of mod_perl is quite important, unless we want to start spending more afternoons with those PHP programmers down at the corner pub. So how would a group like the mod_perl community promote itself in new ways? Well, other professionals often have professional organizations or associations to represent and promote their members. I wonder if there are there enough mod_perl programmers to support something like that. Even if there were, what could be done? Run a few print ads in magazines that system admins read? Hire an ad firm for help in developing our brand? mod_perl coffee mugs? (Tired of that old cup of Java?) Free mod_perl clinics? Hard to imagine any of that actually happening, really. So what's a group of programmers to do? The new web site should help, to some degree, but I'm not sure it will change any manager's mind on the technology they pick to run their applications. Of course, most people here have access to big pipes. So, there's always bulk mail ads. I got mail just today saying that it's an effective way to advertise. In fact I got about ten of those today! -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: Apache::AuthCookie not set cookie really
Skipped Actually, as my application should be 1. simple maintained, 2. maximum count of users - 100 (employees in small software development company) 3. simultaneous login - 5-7 maximum 4. team managers work with money (project budjet, employee's payment per hour and etc) 5. good session solutions require database access while all, what I want to store in sessions, can get from the same database with no great effort I've decided to use simplest authentication module kinda Apache::DBILogin and if someone need real security - SSL. I meant Apache::AuthDBI of course Thank you Sergey Polyakov aka BeerBong Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
cvs commit: modperl-2.0/src/modules/perl modperl_util.c
stas02/01/29 01:50:39
Modified:src/modules/perl modperl_util.c
Log:
- forgot to add that if modperl_tls_get_request_rec fails (which can only
succeed inside request with 'PerlOptions +GlobalRequest', we retun
modperl_global_get_pconf()
Revision ChangesPath
1.37 +6 -2 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- modperl_util.c29 Jan 2002 05:54:20 - 1.36
+++ modperl_util.c29 Jan 2002 09:50:39 - 1.37
@@ -170,7 +170,11 @@
char *classname = NULL;
IV ptr = 0;
-/* get the pool from the current request if applicable */
+/*
+ * if inside request and 'PerlOptions +GlobalRequest' for this interp,
+ * get the pool from the current request
+ * else return the global pool
+ */
if (obj == PL_sv_undef) {
request_rec *r = NULL;
(void)modperl_tls_get_request_rec(r);
@@ -179,7 +183,7 @@
return r-pool;
}
-return NULL;
+return modperl_global_get_pconf();
}
if ((SvROK(obj) (SvTYPE(SvRV(obj)) == SVt_PVMG))) {
cvs commit: modperl-2.0/xs/APR/String - New directory
stas02/01/29 08:23:53 modperl-2.0/xs/APR/String - New directory
cvs commit: modperl-2.0/xs/Apache/Connection Apache__Connection.h
dougm 02/01/29 08:32:25
Modified:xs/Apache/Connection Apache__Connection.h
Log:
get Apache::Connection-client_socket working again
Revision ChangesPath
1.2 +9 -0 modperl-2.0/xs/Apache/Connection/Apache__Connection.h
Index: Apache__Connection.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/Connection/Apache__Connection.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Apache__Connection.h 19 Nov 2001 17:32:46 - 1.1
+++ Apache__Connection.h 29 Jan 2002 16:32:25 - 1.2
@@ -2,6 +2,8 @@
apr_socket_t *mpxs_Apache__Connection_client_socket(pTHX_ conn_rec *c,
apr_socket_t *s)
{
+/* XXX: until minds are made up */
+#if 0
apr_socket_t *socket =
ap_get_module_config(c-conn_config, core_module);
@@ -10,4 +12,11 @@
}
return socket;
+#else
+if (s) {
+c-client_socket = s;
+}
+
+return c-client_socket;
+#endif
}
cvs commit: modperl-2.0/xs/APR/String APR__String.h
stas02/01/29 09:11:06
Modified:xs/maps apr_functions.map modperl_functions.map
xs/APR/String APR__String.h
Log:
- use the mpxs_APR__String_strfsize and format_size as Perl API
- adjust the map files
Revision ChangesPath
1.31 +4 -2 modperl-2.0/xs/maps/apr_functions.map
Index: apr_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- apr_functions.map 29 Jan 2002 07:47:25 - 1.30
+++ apr_functions.map 29 Jan 2002 17:11:06 - 1.31
@@ -247,7 +247,7 @@
apr_lstat
apr_stat
-!MODULE=APR::Strings
+!MODULE=APR::String
apr_collapse_spaces
-apr_cpystrn
apr_fnmatch
@@ -260,11 +260,13 @@
apr_strnatcasecmp
apr_strnatcmp
-apr_tokenize_to_argv
--apr_strfsize
-apr_strtok
-apr_itoa
-apr_ltoa
-apr_off_t_toa
+
+MODULE=APR::String
+ SV *:apr_strfsize | mpxs_APR__String_strfsize | size | format_size
!MODULE=APR::ProcAttr
apr_procattr_create
1.35 +0 -4 modperl-2.0/xs/maps/modperl_functions.map
Index: modperl_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/modperl_functions.map,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- modperl_functions.map 29 Jan 2002 07:47:25 - 1.34
+++ modperl_functions.map 29 Jan 2002 17:11:06 - 1.35
@@ -98,7 +98,3 @@
MODULE=Apache::SubProcess
# ap_subprocess_ won't work
modperl_spawn_proc_prog | MPXS_ | ... | spawn_proc_prog
-
-MODULE=APR::String
- mpxs_APR__String_format_size
-
1.2 +1 -1 modperl-2.0/xs/APR/String/APR__String.h
Index: APR__String.h
===
RCS file: /home/cvs/modperl-2.0/xs/APR/String/APR__String.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- APR__String.h 29 Jan 2002 16:24:34 - 1.1
+++ APR__String.h 29 Jan 2002 17:11:06 - 1.2
@@ -1,5 +1,5 @@
static MP_INLINE
-SV *mpxs_APR__String_format_size(pTHX_ apr_off_t size)
+SV *mpxs_APR__String_strfsize(pTHX_ apr_off_t size)
{
char buff[5];
cvs commit: modperl-2.0/xs/Apache/Time - New directory
stas02/01/29 10:13:21 modperl-2.0/xs/Apache/Time - New directory
cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
dougm 02/01/29 19:29:38
Modified:xs/tables/current/Apache FunctionTable.pm StructureTable.pm
xs/tables/current/ModPerl FunctionTable.pm
Log:
sync
Revision ChangesPath
1.33 +42 -1 modperl-2.0/xs/tables/current/Apache/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/Apache/FunctionTable.pm,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- FunctionTable.pm 29 Jan 2002 05:35:34 - 1.32
+++ FunctionTable.pm 30 Jan 2002 03:29:38 - 1.33
@@ -2,7 +2,7 @@
# !!
# ! WARNING: generated by Apache::ParseSource/0.02
-# ! Mon Jan 28 20:30:40 2002
+# ! Tue Jan 29 19:27:23 2002
# ! do NOT edit, any changes will be lost !
# !!
@@ -1757,6 +1757,11 @@
},
{
'return_type' = 'apr_array_header_t *',
+'name' = 'ap_hook_get_install_transport_filters',
+'args' = []
+ },
+ {
+'return_type' = 'apr_array_header_t *',
'name' = 'ap_hook_get_log_transaction',
'args' = []
},
@@ -1954,6 +1959,28 @@
},
{
'return_type' = 'void',
+'name' = 'ap_hook_install_transport_filters',
+'args' = [
+ {
+'type' = 'ap_HOOK_install_transport_filters_t *',
+'name' = 'pf'
+ },
+ {
+'type' = 'const char * const *',
+'name' = 'aszPre'
+ },
+ {
+'type' = 'const char * const *',
+'name' = 'aszSucc'
+ },
+ {
+'type' = 'int',
+'name' = 'nOrder'
+ }
+]
+ },
+ {
+'return_type' = 'void',
'name' = 'ap_hook_log_transaction',
'args' = [
{
@@ -4121,6 +4148,20 @@
{
'type' = 'request_rec *',
'name' = 'r'
+ }
+]
+ },
+ {
+'return_type' = 'int',
+'name' = 'ap_run_install_transport_filters',
+'args' = [
+ {
+'type' = 'conn_rec *',
+'name' = 'c'
+ },
+ {
+'type' = 'apr_socket_t *',
+'name' = 'csd'
}
]
},
1.29 +34 -5 modperl-2.0/xs/tables/current/Apache/StructureTable.pm
Index: StructureTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/Apache/StructureTable.pm,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- StructureTable.pm 29 Jan 2002 05:35:34 - 1.28
+++ StructureTable.pm 30 Jan 2002 03:29:38 - 1.29
@@ -2,7 +2,7 @@
# !!
# ! WARNING: generated by Apache::ParseSource/0.02
-# ! Mon Jan 28 20:30:43 2002
+# ! Tue Jan 29 19:27:25 2002
# ! do NOT edit, any changes will be lost !
# !!
@@ -64,6 +64,10 @@
'elts' = []
},
{
+'type' = 'ap_HOOK_install_transport_filters_t',
+'elts' = []
+ },
+ {
'type' = 'ap_HOOK_log_transaction_t',
'elts' = []
},
@@ -466,6 +470,31 @@
]
},
{
+'type' = 'ap_LINK_install_transport_filters_t',
+'elts' = [
+ {
+'type' = 'ap_HOOK_install_transport_filters_t *',
+'name' = 'pFunc'
+ },
+ {
+'type' = 'const char *',
+'name' = 'szName'
+ },
+ {
+'type' = 'const char * const *',
+'name' = 'aszPredecessors'
+ },
+ {
+'type' = 'const char * const *',
+'name' = 'aszSuccessors'
+ },
+ {
+'type' = 'int',
+'name' = 'nOrder'
+ }
+]
+ },
+ {
'type' = 'ap_LINK_log_transaction_t',
'elts' = [
{
@@ -2425,10 +2454,6 @@
'name' = 'vhost_lookup_data'
},
{
-'type' = 'apr_socket_t *',
-'name' = 'client_socket'
- },
- {
'type' = 'apr_sockaddr_t *',
'name' = 'local_addr'
},
@@ -2497,6 +2522,10 @@
'name' = 'sbh'
}
]
+ },
+ {
+'type' = 'core_net_rec',
+'elts' = []
},
{
'type' = 'htaccess_result',
1.58 +15 -1 modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- FunctionTable.pm 25 Jan 2002 04:04:12 - 1.57
+++ FunctionTable.pm 30 Jan 2002 03:29:38 - 1.58
cvs commit: modperl-2.0/xs/Apache/Connection Apache__Connection.h
dougm 02/01/29 19:30:24
Modified:xs/Apache/Connection Apache__Connection.h
Log:
conn_rec.client_socket has gone away again
Revision ChangesPath
1.3 +0 -9 modperl-2.0/xs/Apache/Connection/Apache__Connection.h
Index: Apache__Connection.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/Connection/Apache__Connection.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Apache__Connection.h 29 Jan 2002 16:32:25 - 1.2
+++ Apache__Connection.h 30 Jan 2002 03:30:24 - 1.3
@@ -2,8 +2,6 @@
apr_socket_t *mpxs_Apache__Connection_client_socket(pTHX_ conn_rec *c,
apr_socket_t *s)
{
-/* XXX: until minds are made up */
-#if 0
apr_socket_t *socket =
ap_get_module_config(c-conn_config, core_module);
@@ -12,11 +10,4 @@
}
return socket;
-#else
-if (s) {
-c-client_socket = s;
-}
-
-return c-client_socket;
-#endif
}
cvs commit: modperl-2.0/xs/APR/Util - New directory
stas02/01/29 21:16:56 modperl-2.0/xs/APR/Util - New directory
cvs commit: modperl-2.0/xs/maps apr_functions.map
stas02/01/29 21:21:53
Modified:t/protocol/TestProtocol echo_filter.pm
xs/APR/APR apr-test
xs/maps apr_functions.map
Added: t/response/TestAPR util.pm
xs/APR/Util APR__Util.h
Removed: t/response/TestAPR lib.pm
xs/APR/Lib APR__Lib.h
Log:
move APR::Lib = APR::Util
Revision ChangesPath
1.4 +1 -1 modperl-2.0/t/protocol/TestProtocol/echo_filter.pm
Index: echo_filter.pm
===
RCS file: /home/cvs/modperl-2.0/t/protocol/TestProtocol/echo_filter.pm,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- echo_filter.pm20 Jan 2002 18:37:05 - 1.3
+++ echo_filter.pm30 Jan 2002 05:21:52 - 1.4
@@ -6,7 +6,7 @@
use APR::Brigade ();
use APR::Const -compile = qw(SUCCESS EOF);
use Apache::Const -compile = qw(MODE_GETLINE);
-use APR::Lib ();
+use APR::Util ();
sub handler {
my Apache::Connection $c = shift;
1.1 modperl-2.0/t/response/TestAPR/util.pm
Index: util.pm
===
package TestAPR::lib;
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use APR::Util ();
sub handler {
my $r = shift;
plan $r, tests = 3;
my $blen = 10;
my $bytes = APR::generate_random_bytes(10);
ok length($bytes) == $blen;
my $status = APR::password_validate(one, two);
ok $status != 0;
my $str= APR::strerror($status);
t_debug strerror=$str\n;
ok $str eq 'passwords do not match';
0;
}
1;
1.1 modperl-2.0/xs/APR/Util/APR__Util.h
Index: APR__Util.h
===
static MP_INLINE void mpxs_apr_strerror(pTHX_ SV *sv, SV *arg)
{
apr_status_t statcode = mp_xs_sv2_status(arg);
char *ptr;
mpxs_sv_grow(sv, 128-1);
ptr = apr_strerror(statcode, SvPVX(sv), SvLEN(sv));
mpxs_sv_cur_set(sv, strlen(ptr)); /*XXX*/
}
static MP_INLINE void mpxs_apr_generate_random_bytes(pTHX_ SV *sv, SV *arg)
{
int len = (int)SvIV(arg);
mpxs_sv_grow(sv, len);
(void)apr_generate_random_bytes(SvPVX(sv), len);
mpxs_sv_cur_set(sv, len);
}
static XS(MPXS_apr_strerror)
{
dXSARGS;
mpxs_usage_items_1(status_code);
mpxs_set_targ(mpxs_apr_strerror, ST(0));
}
static XS(MPXS_apr_generate_random_bytes)
{
dXSARGS;
mpxs_usage_items_1(length);
mpxs_set_targ(mpxs_apr_generate_random_bytes, ST(0));
}
1.4 +1 -1 modperl-2.0/xs/APR/APR/apr-test
Index: apr-test
===
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/apr-test,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- apr-test 13 Sep 2001 02:39:08 - 1.3
+++ apr-test 30 Jan 2002 05:21:52 - 1.4
@@ -11,7 +11,7 @@
use APR::UUID ();
use APR::Pool ();
use APR::Lock ();
-use APR::Lib ();
+use APR::Util ();
use APR::Base64 ();
use APR::Signal ();
1.32 +1 -1 modperl-2.0/xs/maps/apr_functions.map
Index: apr_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- apr_functions.map 29 Jan 2002 17:11:06 - 1.31
+++ apr_functions.map 30 Jan 2002 05:21:53 - 1.32
@@ -407,7 +407,7 @@
apr_dso_sym
apr_dso_unload
-MODULE=APR::Lib PACKAGE=guess
+MODULE=APR::Util PACKAGE=guess
apr_filename_of_pathname
apr_password_get
apr_password_validate
