Re: $r-headers_out Location and Set-Cookie
On Sat, 9 Aug 2003, gerard uolaquetalestem wrote:
I have the next problem, i am in page A that form points to page B, that is
a modperl2 handler.
This handler makes a job and decides to send a cookie to the browser, and
after to redirect to the same page A who is ready to catch the cookie.
Then the problem is that if i put the two headers, i don't have the cookie
posted, but if i comment the Location header, then i stay at perl handler
location, and if i go manually to page A then i see that the cookie is posted.
So why these two headers doesn't respect themselves?
Resuming
$r-headers_out-{'Set-Cookie'} = $cookie;
$r-headers_out-{'Location'} = $url;
Redirects the page to $url but cookie is not seen by browser
$r-headers_out-{'Set-Cookie'} = $cookie;
#$r-headers_out-{'Location'} = $url;
Location is the perl handler 'localhost/pageB/' (perl handler), if you then go
to localhost/pageA (or simply click BACK button) then the browser DO see
the cookie!
Any idea?
Yep. You need $r-err_headers_out-{'Location'} and you could change to
$r-err_headers_out-{'Set-Cookie'} too.
- nick
--
Nick Tonkin {|8^)
Re: Adding / Modifing Response Headers on mp2
On Thu, 3 Apr 2003, Denis Banovic wrote:
Hi!
I'm trying to figure out, how to Add / Modify the HTTP Headers like
Content Type, Cache aso...
on mod_perl 1 I've used:
$r-send_cgi_header($custom_headers);
but this won't work mod_perl 2...
I've searched in Apache::compat all I've found was the function header_out
that internally calls $r-headers_out()...
Can somebody please tell me how to set the right headers???
TFM is a little hard to find, but when you R http://xrl.us/fix you'll see that
all you need to do to call $r-send_cgi_header() is:
use Apache::Response();
The docs need work, but if you are porting your code from mp1 to mp2 you
really should spend some time reading _all_ the mp2 docs, don't you think?
Start at http://perl.apache.org/docs/2.0/devel/porting/porting.html and just
follow every link from there.
here is the code from Apache::compat
Most of us already have that :)
- nick
--
Nick Tonkin {|8^)
Re: the deprecation of Apache-request in mp2
On Tue, 25 Mar 2003, Stas Bekman wrote:
Lincoln Stein wrote:
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r,
after re-blessing it.
Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request-new($r);
$r = CGI-new($r);
And of course Apache::Request is a subclass of Apache ($r) and it works pretty
well.
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
I sure hope not! I second John Siracusa's post on this. Keep the HTML generation well
away from request parsing, please!
- nick
--
Nick Tonkin {|8^)
Re: speeding up CGI.pm
On Tue, 25 Mar 2003, Lincoln Stein wrote:
I like the idea of that, although the handsprings needed to do ordinary CGI,
mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
separate modules and load them into CGI as needed.
Is Apache::Request in mp2 ready for prime time? We haven't been able to get
it running here (some sort of install problem, my people tell me).
Not at all ready. I do not believe even a beta release has been made.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] adding SERVER_ROOT and SERVER_ROOT/lib/perl to @INC
On Tue, 18 Mar 2003, Geoffrey Young wrote:
Stas Bekman wrote:
Perrin Harkins wrote:
Stas Bekman wrote:
The question is, do we want to have this feature in mp2?
I thought it was cool to have it automatically add a path relative to
the server root, because it makes it feel more like you are writing
real Apache modules, and not just CGI scripts. It's just a warm fuzzy
thing really. I have no problem with dropping that feature and adding
the path myself in startup.pl or httpd.conf.
I'm +0 on adding this feature. While I have never used it myself, I see
no harm in keeping back-compatibility with 1.0. Unless someone has a
reason for not having it I'll commit the patch I've posted earlier.
Is there a performance hit to having @INC include another directory (that
will not be used by many [most?] users)? If so, that's a good argument
against.
in 1.0 I used it all the time and liked having it there. however, I
suspect that doug left it out on purpose - IIRC PerlSwitches was his
answer when this was asked before (maybe it was at a conference, I
can't remember).
I think Doug was right. PerlSwitches is a more flexible, more perlsih and
mod_perlish way of doing it, IMO. Just needs good documentation :)
- nick
--
Nick Tonkin {|8^)
Re: [MP2] Can't dup STDOUT
On Mon, 17 Mar 2003, Thomas Hilbig wrote:
I need to dup the STDOUT handle for a package
(Spreadsheet::WriteExcel) to work properly under
mod_perl.
The code below from the MP1 User documentation now
gives an error in MP2:
use constant IS_MODPERL = $ENV{MOD_PERL};
if (IS_MODPERL) {
tie *OUT, 'Apache';
} else {
open (OUT, -);
}
Under MP2 I get the following error: Can't locate
object method TIEHANDLE via package Apache
Is there an updated method for doing this in MP2?
My environment is : mod_perl/1.99_05-dev, Apache
httpd-2.0.40-8, RedHat 8.0
Given that mod_perl 2 is _beta_ software, you should be using the current
version. It's 1.99_09, and Apache is at 2.0.44. Try the following commands
to get the latest mod_perl sources so you can rebuild:
$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co modperl-2.0
You can get Apache 2.0.44 from the apache site. FWIW once you get the
current apache installed you can rebuild mod_perl more easily than mp1,
since it uses the already-built apache.
Now as for TIEHANDLE, you have not loaded the right module. Try reading
the docs about porting at
http://perl.apache.org/docs/2.0/devel/porting/porting.html and especially
the section on locating missing modules:
http://perl.apache.org/docs/2.0/devel/porting/porting.html#Figuring_Out_What_Modules_Need_to_be_Loaded
This will lead you to do:
$ perl -MApache2 -MModPerl::MethodLookup -le \
'print((ModPerl::MethodLookup::lookup_method(shift))[0])' \
TIEHANDLE
which prints:
There is more than one class with method 'TIEHANDLE'
try one of:
use Apache::RequestIO ();
use Apache::Filter ();
From there you could probably guess that the module you need to load is
Apache::RequestIO, right?
HTH,
- nick
--
Nick Tonkin {|8^)
Re: Where do you put your stuff?
On Mon, 17 Mar 2003, Perrin Harkins wrote:
Goehring, Chuck Mr., RCI - San Diego wrote:
Where do you put your .pm files for application-specific code?
Under mod_perl 1, I just put them in SERVER_ROOT/lib/perl, which is
automatically added to @INC by mod_perl. Can someone confirm if this
still works for mp2?
I do not believe so. In mp2 when you do 'use Apache2();' it modifies your
@INC, but adds only PERL_LIB/Apache2 ... so my @INC inside my mp2 server
is:
/home/debug/perl/lib/site_perl/5.8.0/i386-freebsd/Apache2
/home/debug/perl/lib/5.8.0/i386-freebsd
/home/debug/perl/lib/5.8.0
/home/debug/perl/lib/site_perl/5.8.0/i386-freebsd
/home/debug/perl/lib/site_perl/5.8.0
/home/debug/perl/lib/site_perl
.
Of course you can just put a use lib in your startup.pl, assuming that
you are doing this for a server where you know the locations of things.
I do that anyway since I want to keep my application code separate from
the Apache/perl/mod_perl lib dirs. But that's just me. I'm a neat freak. I
used to use Partition Magic on my Windows boxes to make C: for the OS, D:
for apps, and E: for data, until I found out that Windows apps install
themselves wherever they feel like it :)
- nick
--
Nick Tonkin {|8^)
RE: Tracing double accesshandler invocation
Hi Ric,
This has been a nightmare trying to debug, but I think I've found where
the cause is in my module.
In my Access handler I have some code designed to skip Access handling for
images (let the html pages take care of that). The code calls
$r-lookup_uri to check on the content type of the file being requested,
which, according to the mod_perl cookbook, forces the subrequest back
through the Access and Auth stages (recipe 3.15, pp. 114-116).
if ($r-lookup_uri($r-uri)-content_type =~ /image/) {
return Apache::DECLINED;
}
Do you have this, or something similar, in your code?
My debugging was greatly complicated by the fact the the Apache::Test
framework apparently requests / from the server as a ping before
starting any tests. So I was consistently getting five calls to the Access
handler for the four tests in t/hooks.access.t when reconfigured to use
TesHooks::access for Location / -- watch out for this, all.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Fri, 14 Mar 2003, Richard Clarke wrote:
The only thing which it does which is affected by anything outside of its
immediate environment is call, $r-prev. This shouldn't call the
accesshandler though... should it?
Erm, doh, not sure why I said this. This only happens when a 403 happens and
the user is sent to the /login location. So my actual AccessHandler doesn't
do anything which even resembles a subrequest.
can you post the handler?
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Fri, 14 Mar 2003, Richard Clarke wrote:
package AC::Centry::Access;
$AC::Centry::Access::VERSION = qw$Revision: 1.2 $[1];
use strict;
use Apache::Constants qw(:common);
use AC::Centry::Tool();
# handler()
# Process requests to protected URI's
sub handler {
my $r = shift;
my $uri = $r-the_request;
return OK unless $r-is_initial_req; # stops dbl execution
Stops dbl execution _after_ this point, of course. If you request a
directory, the server will return an internal redirect to $dir/index.html
(or whatever) -- that would make your handler run twice up to this point.
Try taking that code out and running the test with a URL that points to a
file.
Also, I think it's better to return DECLINED from your Access handler if
you're not returning FORBIDDEN, rather than OK, since there may be other
handlers that need to work on the request. And if not now, maybe in the
future.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Fri, 14 Mar 2003, Richard Clarke wrote:
sub handler {
my $r = shift;
my $uri = $r-the_request;
return OK unless $r-is_initial_req; # stops dbl execution
Stops dbl execution _after_ this point, of course. If you request a
directory, the server will return an internal redirect to $dir/index.html
(or whatever) -- that would make your handler run twice up to this point.
I'm not sure what you mean.
The reason that I put that code there is because if it's not there then the
accesshandler is always run twice.
There seems to be a subrequest triggering the accesshandler, yet I'm not
explicitly performing any subrequests.
What I meant was that if you request http://yourdomain.com/some/path then
the server will return a redirect to
http://yourdomain.com/some/path/index.html, which will cause tha access
handler to be invoked a second time.
Ideally I would like to find someway to trace the who/what/where/why of
handler execution. Running with PERL_TRACE left me none the wiser so I was
hoping a user might know a better way?
Richard.
- nick
--
Nick Tonkin {|8^)
Re: Newbie help with mod-perl 2.0
On Tue, 11 Mar 2003, Svein E. Seldal wrote:
Hi,
Thanks for your help. I'm closer to my goal, thanks to you. However, I
have more questions, and I'd hoped you'd enlighten me. I'm reading a lot
of documentation on the web about MP2, but I need some more information
to clear things out, and to stitch all these small threads of
information together.
First of all, my intentions was to use the new MP2 methods only, because
I'm redesigning things from scratch. And thus having to use
Apache::compat is a slightly setback, isn't it?
Yes. You are doing the Right Thing.
Do you have any idea
when the new MP2-ish methods will be ready? Especially Apache::Request?
It's under development. The others are all there, or what specifically are
you lacking?
Meanwhile you use CGI.pm ...
With other words Apache::Request will be the new MP2 way to do things in
the future?
Yes. Subscribe to [EMAIL PROTECTED] to get the progress updates.
Now, testing revealed that $r-args() is only containing the
query-string that is part of the URI (now I would guess you say daahh)
-- this is usually used in context with GET requests.
When I send a POST request, the query-string will be stored in the
contents of the message, and not in $r-args(). However, I still need to
parse the string as with the GET message.
Last but least, I need to support GET form-data (to support file
uploads), which leaves us with a third type of argument syntax.
Are there any methodes that I can use (now) to parse these POST
requests, or do I have to write a parser myself? Will Apache::Request be
able to handle these cases? (Because if it will, I can probably settle
for args() and content() now, and use my own parser until
Apache::Request shows up.)
CGI.pm should be able to do all of the above and many of its methods
are the same as Apache::Request's.
HTH,
- nick
--
Nick Tonkin {|8^)
Re: [mp2] Documentation
On Mon, 10 Mar 2003 [EMAIL PROTECTED] wrote:
Hi -
I'm getting frustrated. I'm trying to parse the
incoming uri (url) in mod_perl 2, and I can't
seem to be able to find documentation. For
example, Nick gave me the following snippet
of code last week:
my $uri = APR::URI-parse($r-pool,
$r-construct_url);
$uri-scheme('https');
my $new_uri = $uri-unparse;
OK. Now where can a find documentation for:
* methods/members in $r?
* methods/members in APR?
* methods/members in uri?
Have you tried the pretty good (tm) search engine on the mod_perl site
itself? Note that you can restrict your search to the 2.0 docs. For
example, searching for `APR::URI-parse' gave me one result:
http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache__URI_E_gt_parse__ruri___
which has exactly what I need.
Now of course it also refers me to the man page for APR::URI, which does
not (apparently) exist.
I think it may be harder for you, Beau, since you started working with
mod_perl with this beta 2.0 version, and don't have a grounding in
mod_perl from v. 1.0.
The docs work best when you know what you want to do and how to do it in
mp1, and can then find the equivalent for mp2.
code. I wanted to examine APR, for example,
and look what I found:
package APR;
use DynaLoader ();
our $VERSION = '0.01';
our @ISA = qw(DynaLoader);
#dlopen(APR.so, RTDL_GLOBAL); so we only need
#to link libapr.a once
sub dl_load_flags { 0x01 }
unless (defined APR::XSLoader::BOOTSTRAP) {
__PACKAGE__-bootstrap($VERSION);
*APR::XSLoader::BOOTSTRAP = sub () { 1 };
}
1;
__END__
Yep, not very enlightening if you're not a C guru.
- nick
--
Nick Tonkin {|8^)
Re: apache::sandwich
On Mon, 10 Mar 2003, Brent Baude wrote:
I recently uprgaded from a pre-RedHat8 system to RedHat 8. I used the
Apache::Sandwich module to specify a directory and footer filename in the
directives to allow me to include footer files dynamically (without having
to specify an include statement in each file served). Is there something
like this module or an alternative for Apache 2 versions?
mod_perl 2 supports output filtering, which could provide a streamlined
way of doing what Apache::Filter does fairly trivially AFAIK. But you'd
have to read up on filters and implement it yourself.
Another option would be for you to port Apache::Filter to run under mp2.
Then your code as well as anyone else's who uses that module would run
unchanged under mp2. That would be a Good Thing and you'd be a mod_perl
hero. People on this list would help if you got stuck, and the
documentation for porting is getting quite extensive.
This doc: http://perl.apache.org/docs/2.0/devel/porting/porting.html is
what you want.
Good luck,
- nick
--
Nick Tonkin {|8^)
Re: apache::sandwich
D'oh, please s/Apache::Filter/Apache::Sandwich/ in my earlier reply.
Sorry.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] changing http:// to https: in TransHandler
On Sat, 8 Mar 2003 [EMAIL PROTECTED] wrote:
Hi -
I'm not much of a mod_perl scripter (yet), but having been
totally defeated my mod_rewrite, I am trying to use mod_perl
to push clients into using https when accessing a particular
server (I am using named-based virtual hosting).
I want to do something like this (the real one will be
more complicated - but this is a baby test):
-in httpd.conf-
PerlTransHandler +MyApache::ForceSecure
-handler-
package MyApache::ForceSecure;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::Const -compile = qw(DECLINED);
sub handler
{
my $r = shift;
my $url = $r-url;
if ($url =~ m{^http://bcbk}i) {
$url =~ s/^http:/https:/i;
$r-url ($url);
}
return Apache::DECLINED;
}
1;
Which is great, but there is *no* $r-url. I know there is a $r-uri, but
how can I get to the whole ball of wax: from http://...? I can't find
it in the docs.
Aloha = Beau;
Beau:
I _just_ went through this on my system. You would probably want to use
the following to change the URI as you wish:
my $uri = APR::URI-parse($r-pool, $r-construct_url);
$uri-scheme('https');
my $new_uri = $uri-unparse;
However, the overall strategy is probably not what you want, due to the
way SSL works. When a browser requests a secure connection, the SSL
connection (to the secure port) is established _before_ even the HTTP
connection. Thus it is impossible to change the scheme (http vs https)
once you have arrived at your server. The only way to do this with a Perl
handler is to generate a 302 external redirect.
mod_rewrite can be complicated, sure, but I do think it's the way to
go in this situation. You need:
- two sub-domains in DNS, let's say www.my_domain.com and secure.my_domain.com
- a sub-directory /secure in your webdocs root (or something else able to matched with
a regex)
- the following in your httpd.conf:
Listen 80
Listen 443
NameVirtualHost 12.34.56.789:80
NameVirtualHost 12.34.56.789:443
VirtualHost 12.34.56.789:80
ServerName www.my_domain.com
RewriteEngine on
RewriteCond %{REQUEST_URI} /secure/
RewriteRule ^/(.*)$ https://secure.my_domain.com/$1 [R,L]
/VirtualHost
VirtualHost 12.34.56.789:443
ServerName secure.my_domain.com
RewriteEngine on
RewriteCond %{REQUEST_URI} !/secure
RewriteRule ^/(.*)$ http://www.my_domain.com/$1 [R,L]
/VirtualHost
This allows you to have relative links on all your pages. All links on
www.my_domain.com will point to http://www. on port 80, and all links on
secure.my_domain.com will point to https://secure. on port 443. The server
will simply rewrite and redirect all links that do not match either
/secure/ or !/secure.
Hope this helps,
- nick
PS If you have more than one domain needing to use https, you can put it
on an arbitrary port so long as you configure the server (not apache) to
listen on it, and then hard-code the port number in the mod_rewrite rule.
--
Nick Tonkin {|8^)
Re: [mp2] changing http:// to https: in TransHandler
On Sun, 9 Mar 2003, Jason Galea wrote:
sorry if OT..
Yes, it's OT. Please take SSL questions to an ssl-related list. Or, since
the previous post contained cut-n-paste instructions, you could have tried
it! :)
please tell me I'm wrong (I'll be a happy camper), but I thought that you
couldn't use name virtual server for SSL.
The basic answer to your question is that you only need unique IP-port
combinations to run multiple SSL virtual hosts using NameVirtualHost.
However, requests to any SSL virtual host other than the one running on
port 443 (the standard https port) will have to specify the port in the
request.
I suggest spending some time with the docs for mod_ssl, if that's what
you're using.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Thu, 6 Mar 2003, Stas Bekman wrote:
Nick Tonkin wrote:
On Wed, 5 Mar 2003, Richard Clarke wrote:
Hi,
I'm trying to figure out why my accesshandler is getting triggered twice
for each request that I make. I'm 100% sure that I'm doing no explicit
lookups/redirects anywhere in my code. The particular uri I am fetching
should only invocate an accesshandler followed by a contenthandler.
After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I
think I'm still non the wiser.
Testing for $r-is_initial_req solves the problem but I'm more interested
in finding out exactly why it's being called twice.
Any tips for tracing this easier?
Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same
thing used to happen on mp1 too.
I too would very much like to figure this out. I sort of suspect it is in
how the httpd.conf auth* directives are specified, but I've never had the
time to really muck around with them.
If you provide me a simple mp2 setup where this happens, I can debug it.
However if I run with mp2:
t/TEST -v hooks/access
and log from TestHooks/access.pm every time an access handler is called, I can
see it called only once per request. So may be play with this test's config
until you break it. if you succeed to break it, that would be the easiest for
me to reproduce your problem.
This is on my list of things to do.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] CGI redirects incorrectly handled?
How are you telling the server to redirect? You do know it's different
from mp1, right?
In mp2 you need to do:
my $location = 'http://foo.bar.baz';
$r-headers_out-{'Location'} = $location;
# Or use $r-err_headers_out-{'Location'} which you will have
# to do with any other headers you want to have sent with the
# redirect, such as cookies
return Apache::HTTP_MOVED_TEMPORARILY;
# Apache::REDIRECT still supported, this is the correct
# constant though.
On Wed, 5 Mar 2003, Mark James wrote:
I'm having CGI redirect problems mp2 (cvs).
How are you telling the server to redirect? You do know it's different
from mp1, right?
In mp2 you need to do:
my $location = 'http://foo.bar.baz';
$r-headers_out-{'Location'} = $location;
# Or use $r-err_headers_out-{'Location'} which you will have
# to do with any other headers you want to have sent with the
# redirect, such as cookies
return Apache::HTTP_MOVED_TEMPORARILY;
# Apache::REDIRECT still supported, this is the correct
# constant though.
Now that I think about it, maybe you're using CGI.pm to do your redirect?
If so, maybe the code in CGI.pm has not been correctly updated?
Hope this helps.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Wed, 5 Mar 2003, Richard Clarke wrote:
Hi,
I'm trying to figure out why my accesshandler is getting triggered twice
for each request that I make. I'm 100% sure that I'm doing no explicit
lookups/redirects anywhere in my code. The particular uri I am fetching
should only invocate an accesshandler followed by a contenthandler.
After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I
think I'm still non the wiser.
Testing for $r-is_initial_req solves the problem but I'm more interested
in finding out exactly why it's being called twice.
Any tips for tracing this easier?
Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same
thing used to happen on mp1 too.
I too would very much like to figure this out. I sort of suspect it is in
how the httpd.conf auth* directives are specified, but I've never had the
time to really muck around with them.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Wed, 5 Mar 2003, Richard Clarke wrote:
Hi,
I'm trying to figure out why my accesshandler is getting triggered twice
for each request that I make. I'm 100% sure that I'm doing no explicit
lookups/redirects anywhere in my code. The particular uri I am fetching
should only invocate an accesshandler followed by a contenthandler.
After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I
think I'm still non the wiser.
Testing for $r-is_initial_req solves the problem but I'm more interested
in finding out exactly why it's being called twice.
Any tips for tracing this easier?
Ric.
Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same
thing used to happen on mp1 too.
I too would very much like to figure this out. I sort of suspect it is in
how the httpd.conf auth* directives are specified, but I've never had the
time to really muck around with them.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] CGI redirects incorrectly handled?
On Thu, 6 Mar 2003, Mark James wrote:
Nick Tonkin wrote:
Now that I think about it, maybe you're using CGI.pm to do your redirect?
If so, maybe the code in CGI.pm has not been correctly updated?
Yes Nick, I'm using CGI.pm version 2.91 (the latest). Its redirect code
sends a Status: 302 Moved.
That wouldn't be the problem, if there is one. The problem would be in how
CGI.pm sets the Location header, noting the differences in syntax I
pointed out earlier.
You might try one of the CGI mailing lists to see if anyone there knows
whether the code is compliant with what I posted before. The documentation
is at http://xrl.us/dfb
Otherwise, try setting the redirect location manually as I showed you and
see if the problem persists.
- nick
--
Nick Tonkin {|8^)
Re: file upload under mod_perl 2 wihout CGI.pm
On Tue, 4 Mar 2003, Egor Korablev wrote:
Hello.
How can I get file upload from form using mod_perl 2 without CGI.pm?
thx
You can't. At least not in an easy way, which I guess is what you want.
Apache::Request is not ported to mod_perl 2 yet. Time to fall back in love
with CGI.pm, just like when you were a young man and the web was even
younger :)
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
On Thu, 27 Feb 2003, Jean-Michel Hiver wrote:
Hi List,
In theory Authentication / Authorization handlers are very cool, because
the application underneath it doesn't need to know the logic of it, and
as long as you design web applications with nice, RESTful, sensible URIs
it would all work beautifully.
BUT, I cannot figure out how to 'ask' apache wether a request would
succeed or not. I'm wondering wether there would be a way to do:
my $ok = $r-would_be_authorized ($uri);
# or
my $ok = $r-would_be_authorized ($uri, 'GET');
# or
my $ok = $r-would_be_authorized ($uri, 'POST', $fh);
This would be handy because for example in your web application you
might want certain controls or links to be replaced by proper messages
rather than directing the user to a location that he/she doesn't have
access to.
If I missed something obvious please point out a URI so that I can RTFM!
All ideas appreciated!
Salut,
I think this may be solved by architecture. If you have an Authz layer
maybe it needs to be called sooner than right when you need it.
I have a Session-based auth system. When the user successfully
authenticates the Auth handler does a lookup in a db where we store all
users' authz information. The db has an access level for each user for
each widget in the application. These are all loaded into a hashref and
stored in the serverside session. An encrypted cookie has the key to the
session.
All of this is tied into the UI such that the user's authz level
determines the content they see. Data such as '$student-first_name' are
displayed by a UI handler according to perms; the UI's methods can write
out either:
First Name: $val or
First Name: input type='text' name ='first_name' val='$val' or
whatever, depending on the user's perms.
HTH,
- nick
--
Nick Tonkin {|8^)
Re: mod_perl Developer's Cookbook
On Thu, 27 Feb 2003, Gazi, Nasser (London) wrote:
A question about mod_perl Developer's Cookbook by Young, Lindner and
Kobes:
Is this book still relevant and worth buying for mod_perl2 ?
Yes, but there are parts that are different for mp2, and other things that
are omitted. Remember: mp2 is not finished!
(I'm about to
dive into web development using Apache/mod_perl and intend to go straight to
mp2).
I would spend a little time on a dev server playing with mp1. There is a
lot more documentation, support and community wisdom available there. By
the time you get up to speed mp2 might be closer to its final version ...
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
On Thu, 27 Feb 2003, Geoffrey Young wrote:
I've decided that the
return DECLINED if $r-is_inital_req;
bit is a bad idea. after a few hours debugging an authorization
application, I realized that this does nothing but cause problems - if you
DECLINE a subrequest then it's picked up by mod_auth which, if you're not
configured for flat file auth (in addition to your custom auth), mod_auth
will return AUTH_REQUIRED (or worse).
you may want to
return OK if $r-is_inital_req;
but DECLINED is almost certainly a bad idea.
What was the idea behind
return DECLINED if $r-is_inital_req;
in auth handlers in the first place?
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
On Thu, 27 Feb 2003, Jean-Michel Hiver wrote:
I think this may be solved by architecture. If you have an Authz layer
maybe it needs to be called sooner than right when you need it.
I have a Session-based auth system. When the user successfully
authenticates the Auth handler does a lookup in a db where we store all
users' authz information. The db has an access level for each user for
each widget in the application. These are all loaded into a hashref and
stored in the serverside session. An encrypted cookie has the key to the
session.
Yes, but you're then making the authorization layer inseparable from
your applicative layer, and hence you loose the interest of using
separate handlers.
True. For the type of application I deal with, where authorization levels
and security are paramount, this is not a bad thing. And really, in my
system, the UI modules only need to know the user's authz level (0-4) to
produce content ... they do not care how the authz level was generated.
- nick
--
Nick Tonkin {|8^)
Re: Authorization question
On Thu, 27 Feb 2003, Bill Moseley wrote:
On Thu, 27 Feb 2003, Perrin Harkins wrote:
Jean-Michel Hiver wrote:
Yes, but you're then making the authorization layer inseparable from
your applicative layer, and hence you loose the interest of using
separate handlers.
It's pretty hard to truly separate these things. Nobody wants to use
basic auth, which means there is a need for forms and handlers. Then
you have to keep that information in either cookies or URLs, and there
is usually a need to talk to an external data database with a
site-specific schema. The result is that plug and play auth schemes
only work (unmodified) for the simplest sites.
Anyone using PubCookie?
http://www.washington.edu/pubcookie/
All C, no?
- nick
--
Nick Tonkin {|8^)
Re: [mp2] send_http_header() can't be called before the responsephase
On Thu, 20 Feb 2003, Stas Bekman wrote:
Stas Bekman wrote:
Nick Tonkin wrote:
[...]
send_http_header() can't be called before the response phase
Nick, I've just committed a better solution. Please verify that it works for you.
Now that the uri bug is fixed, this fix works fine, Stas. No complaints
when calling send_http_header in my Auth handler. So now I've taken it out
:)
- nick
--
Nick Tonkin {|8^)
Re: [mp2] Cookie behavior discrepancy in Auth* handlers ?
On Wed, 19 Feb 2003, Nick Tonkin wrote:
Hi all,
Cookies driving me nuts as usual but I think the problem appears to be
related to which handler phase we are in.
Basically, the same call to read the cookies works in the PerlHandler but
not in the PerlAccessHandler.
Responding to my own post here, to keep the archive complete. (That's the
only reason, since there doesn;t seem to be anyone else using cookies for
auth stuff in mp2 ...)
Testing has shown that the first diagnosis was correct. Stas tracked it
down to %ENV not getting populated prior to the Response phase. He is
working on a fix.
Meanwhile I'm getting around the problem by subclassing CGI::Cookie (which
we are using since Apache::Request is not ported to mp2 yet) thusly:
package WM::Auth::Cookie;
use strict;
use warnings;
use CGI::Cookie;
WM::Auth::Cookie::ISA = qw/CGI::Cookie/;
sub fetch {
my $class = shift;
my $r = shift;
my $raw_cookie = $r-headers_in-{'Cookie'};
return () unless $raw_cookie;
return $class-parse($raw_cookie);
}
1;
the only difference in API being that one must replace
my $cookie = CGI::Cookie-fetch();
with
my $cookie = WM::Auth::Cookie-fetch($r);
Looking forward to the proper fix though.
- nick
--
Nick Tonkin {|8^)
[mp2] porting tip - must return OK from content-handlers
I had some handlers that did not explicitly return OK -- just printed the
coontent and quit. In apache1/mp1 this 'worked' fine.
After migrating to apache2/mp2 these handlers delivered the content to the
browser but then printed a 500 error message to the browser but _not_ to
the error log.
Just a heads-up.
- nick
--
Nick Tonkin {|8^)
[mp2] porting tip - DefaultType text/html
As the docs say $r-send_http_header is deprecated because it is unneeded
in mp2 ... but $r-content_type must be set.
DefaultType is set by default to text/plain in httpd.conf, so browsers
that strictly apply content_type (eg Opera 7) were showing the content as
HTML source.
I had several handlers that simply called $r-send_http_header so
replacing each occurence with $r-content_type wasn't much of an
improvement in code cleanliness and simplicity, if that's what the goal of
eliminating send_http_headers was in the first place.
Therefore, I changed DefaultType from text/plain to text/html and voila --
I don't have to set $r-content_type after all but rather can just delete
all the $r-send_http_headers calls.
YMMV, of course, if you have other parts of your webserver that do not
supply a content-type :)
- nick
--
Nick Tonkin {|8^)
[mp2] what is GEN1 and why is it my log?
Hi,
In my logs when dumping a warn() I see this occasionally:
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28, GEN1 line 245.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
Anyone know what GEN1 is and why it appears every so often?
Thanks,
- nick
--
Nick Tonkin {|8^)
Re: Apache::TicketAccess
On Thu, 20 Feb 2003, Scott Alexander wrote:
On Thu, 20 Feb 2003, Scott Alexander wrote:
If I set my browser to david:8080/login.pl then everything works okay,
Cookie gets set, and my session is current until I logout.
So the setup is something to do with mod_proxy on the proxy server.
Is it the cookie doesn't get sent back thru the reverse proxy?
As Perrin said, you need to see what is actually happening. Dumping the
headers is a great way to start. Right at the top of your handler do
sub handler {
my $r = shift;
warn $r-as_string;
If the cookies are being sent to the browser, they'll be there. If they
are and it's still not working, you need to look at the reading of the
cookies in your module.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] what is GEN1 and why is it my log?
On Fri, 21 Feb 2003, Stas Bekman wrote:
Ged Haywood wrote:
On Thu, 20 Feb 2003, Nick Tonkin wrote:
Hi,
In my logs when dumping a warn() I see this occasionally:
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28, GEN1 line 245.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28.
Anyone know what GEN1 is
I think it comes from Symbol.pm. It's a handle: the string GEN is
in the source, the digit is just picked by the package when it opens a
file/socket/whatever it's doing.
Most likely.
and why it appears every so often?
Try adding
use Carp;
$SIG{__WARN__} = \Carp::cluck;
in your startup.pl, this may shed some light. what's the call at line 28 of
Access.pm? May be some debug print was forgotten in the modperl source code.
No, the warn is mine. It just says:
my $ip = $r-connection-remote_ip;
warn $ip;
Here's the output with Carp::cluck -
XX.XXX.XXX.X at /home/wm/perl/WM/Auth/Access.pm line 28, GEN5 line 245.
WM::Auth::Access::handler('Apache::RequestRec=SCALAR(0x85c5914)') called at -e
line 0
eval {...} called at -e line 0
XX.XXX.XXX.X at /home/wm/perl/WM/Auth/Access.pm line 28.
WM::Auth::Access::handler('Apache::RequestRec=SCALAR(0x85b4b24)') called at -e
line 0
eval {...} called at -e line 0
one with GEN5 and one right after it with nothing (as are almost all of
them).
- nick
--
Nick Tonkin {|8^)
[mp2] $r-server()-server_hostname compatibility?
server_hostname is not documented on the list. Anyone know the equivalent please? - nick
[mp2] warnings
Is it possible to combine the recommended syntax:
use warnings FATAL = 'all', NONFATAL = 'redefine';
with the ability to turn warnings on in httpd.conf with PerlSwitches -w?
- nick
Nick Tonkin {|8^)
[mp2] handler running twice for one request
Hi all,
I my httpd.conf I have:
Location /
AddType text/html .html
PerlAccessHandler WM::Auth::Access
/Location
And in my handler I have:
package WM::Auth::Access;
use strict;
use warnings;
use Time::HiRes qw(gettimeofday);
sub handler {
my $r = shift;
my $s = $r-server;
$s-warn( [$$] beginning at . gettimeofday . with [ . $r-uri . ] );
if (! $r-is_initial_req) {
$s-warn( [$$] \$r-is_initial_req false; declining at . gettimeofday );
return Apache::DECLINED;
} elsif ($r-lookup_uri($r-uri)-content_type =~ /image/) {
$s-warn( [$$] image requested; declining at . gettimeofday );
return Apache::DECLINED;
}
[ ... ]
When I request /img/logo.gif, I get:
[warn] [1168] beginning at 1045540634.07781 with [/img/logo.gif]
[warn] [1168] beginning at 1045540634.07883 with [/img/logo.gif]
[warn] [1168] $r-is_initial_req false; declining at 1045540634.07908
[warn] [1168] image requested; declining at 1045540634.07941
So, my quesstions are:
1) Why two times through the handler?
2) Why does the second time through start before the first one apparently
gets to the conditional?
3) Why is a simple request like that not the is_initial_req
4) If the first time through it reurns DECLINED because it's not an
initial req, how come it goes through again?
5) What the heck is going on here?
Thanks,
- nick
Nick Tonkin {|8^)
[mp2] Cookie behavior discrepancy in Auth* handlers ?
Hi all,
Cookies driving me nuts as usual but I think the problem appears to be
related to which handler phase we are in.
Basically, the same call to read the cookies works in the PerlHandler but
not in the PerlAccessHandler.
in Access.pm I have :
use CGI;
use CGI::Cookie;
sub handler {
my $r = shift;
warn $r-as_string;
my $cookies = fetch CGI::Cookie;
warn Access Dumping Cookies:\n . Dumper($cookies);
return Apache::DECLINED if $r-uri =~ m|/authenticate|
Access.pm is called thus:
Location /
AddType text/html .html
AddHandler server-parsed .html
Options +Includes
PerlSetVar WM_Auth_Domain wm.tonkinresolutions.com
PerlAccessHandler WM::Auth::Access
/Location
in Auth.pm I have :
use CGI;
use CGI::Cookie;
sub handler {
my $r = shift;
warn $r-as_string;
my $cookies = fetch CGI::Cookie;
warn Auth Dumping Cookies:\n . Dumper($cookies);
Auth.pm is called thus:
ErrorDocument 403 /authenticate
Location /authenticate
sethandler perl-script
PerlHandler WM::Auth::Auth
/Location
I request /authenticate when I already have an 'auth' cookie on the
browser, and I get this:
Access Dumping Headers:
GET /authenticate?foo HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: wm.tonkinresolutions.com
Connection: Keep-Alive
Cookie: foo=bar;
remembered_uri=https%3A%2F%2Fwm.tonkinresolutions.com%2Findex.html;
auth=hash6032ccbfd909f951dcfbd804441163bcgroup_namerootsession580a5fc6a0215f2eaecde2e6d5554b07usernick_time1045689878expires60
INCLUDED (null)
Access Dumping Cookies:
$VAR1 = undef;
Auth Dumping Headers:
GET /authenticate?foo HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: wm.tonkinresolutions.com
Connection: Keep-Alive
Cookie: foo=bar;
remembered_uri=https%3A%2F%2Fwm.tonkinresolutions.com%2Findex.html;
auth=hash6032ccbfd909f951dcfbd804441163bcgroup_namerootsession580a5fc6a0215f2eaecde2e6d5554b07usernick_time1045689878expires60
HTTP/1.1 (null)
Auth Dumping Cookies:
$VAR1 = {
'auth' = bless( {
'value' = [
'hash',
'6032ccbfd909f951dcfbd804441163bc',
'group_name',
'root',
'session',
'580a5fc6a0215f2eaecde2e6d5554b07',
'user',
'nick',
'_time',
'1045689878',
'expires',
'60'
],
'name' = 'auth',
'path' = '/'
}, 'CGI::Cookie' ),
'foo' = bless( {
'value' = [
'bar'
],
'name' = 'foo',
'path' = '/'
}, 'CGI::Cookie' ),
'remembered_uri' = bless( {
'value' = [
'https://wm.tonkinresolutions.com/index.html'
],
'name' = 'remembered_uri',
'path' = '/'
}, 'CGI::Cookie' )
};
Can anyone offer a clue?
Thanks,
- nick
--
Nick Tonkin {|8^)
Re: [mp2] send_http_header() can't be called before the responsephase
On Thu, 20 Feb 2003, Stas Bekman wrote:
Stas Bekman wrote:
Nick Tonkin wrote:
[...]
send_http_header() can't be called before the response phase
Nick, I've just committed a better solution. Please verify that it works for you.
I'll have a go as soon as poss.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] $r-server()-server_hostname compatibility?
On Thu, 20 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
server_hostname is not documented on the list. Anyone know the equivalent
please?
it hasn't changes from 1.0. I thought we have been through this already, just
yesterday.
We did. The list is resending mail. Or maybe the mail was trying to get
through?
It's not quite the same: it's $r-get_server_name or
$r-server-server_name in mp2 versus $r-server-server_hostname in mp1.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] warnings
On Thu, 20 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
Is it possible to combine the recommended syntax:
use warnings FATAL = 'all', NONFATAL = 'redefine';
with the ability to turn warnings on in httpd.conf with PerlSwitches -w?
-w is the same as:
use warnings 'all';
then you can override things in your code using the warnings pragma.
Though I should add a note that NONFATAL was introduced only in 5.8, so you
probably don't want to use it.
I think that is already clear in the docs at
http://perl.apache.org/docs/2.0/user/coding/coding.html#Auto_Reloading_Modified_Modules_with_Apache__Reload
I just wanted to know if it was possible to get the same effect somehow
using PerlSwitches in httpd.conf -- I guess not.
If I put the 'use warnings;' pragma in startup.pl it will be server-wide,
though, won't it?
- nick
--
Nick Tonkin {|8^)
Re: [mp2] handler running twice for one request
On Thu, 20 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
Hi all,
I my httpd.conf I have:
Location /
AddType text/html .html
PerlAccessHandler WM::Auth::Access
/Location
And in my handler I have:
package WM::Auth::Access;
use strict;
use warnings;
use Time::HiRes qw(gettimeofday);
sub handler {
my $r = shift;
my $s = $r-server;
$s-warn( [$$] beginning at . gettimeofday . with [ . $r-uri . ] );
if (! $r-is_initial_req) {
$s-warn( [$$] \$r-is_initial_req false; declining at . gettimeofday );
return Apache::DECLINED;
} elsif ($r-lookup_uri($r-uri)-content_type =~ /image/) {
$s-warn( [$$] image requested; declining at . gettimeofday );
return Apache::DECLINED;
}
[ ... ]
When I request /img/logo.gif, I get:
[warn] [1168] beginning at 1045540634.07781 with [/img/logo.gif]
[warn] [1168] beginning at 1045540634.07883 with [/img/logo.gif]
[warn] [1168] $r-is_initial_req false; declining at 1045540634.07908
[warn] [1168] image requested; declining at 1045540634.07941
So, my quesstions are:
1) Why two times through the handler?
2) Why does the second time through start before the first one apparently
gets to the conditional?
3) Why is a simple request like that not the is_initial_req
4) If the first time through it reurns DECLINED because it's not an
initial req, how come it goes through again?
5) What the heck is going on here?
do you have mod_dir configured? but then you aren't requisting /
I do. But you're right, I'm not.
Run with the tracing enabled and you will be able to debug it easily:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlTrace_
Heh. I am going to make a new debugging installation to keep around
permanently!!!
- nick
--
Nick Tonkin {|8^)
Re: [mp2] $r-server()-server_hostname compatibility?
On Thu, 20 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
On Thu, 20 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
server_hostname is not documented on the list. Anyone know the equivalent
please?
it hasn't changes from 1.0. I thought we have been through this already, just
yesterday.
We did. The list is resending mail. Or maybe the mail was trying to get
through?
weird
It's not quite the same: it's $r-get_server_name or
$r-server-server_name in mp2 versus $r-server-server_hostname in mp1.
No, it's exactly the same in mp1 and mp2: $r-server-server_hostname
Confusing. The docs mention server_name() at
http://perl.apache.org/docs/2.0/api/Apache/RequestUtil.html#METHODS
there is no such a thing as $r-server-server_name
plus there is $r-get_server_name in 2.0
That's what I'm using for convenience anyway.
- nick
--
Nick Tonkin {|8^)
[mp2] $r-server-server_hostname() compatibility?
Does anyone know the equivalent directive for
$r-server()-server_hostname()
?
Thanks,
- nick
--
Nick Tonkin {|8^)
[mp2] $r-server_name not working
I have
use Apache::RequestRec;
use Apache::RequestUtil;
[ ... ]
$server_name = $r-server_name;
This fails with:
Can't locate object method server_name via package Apache::RequestRec
(even though server_name() is in RequestUtil ...)
I will try to test a bit but I may have to focus on getting a 1.x
installation built on this box ...
- nick
--
Nick Tonkin {|8^)
Re: [mp2] $r-server-server_hostname() compatibility?
On Wed, 19 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
Does anyone know the equivalent directive for
$r-server()-server_hostname()
it's right there:
use Apache::Server;
$r-server-server_name;
Well, it doesn't work as advertised, I think.
package NPT::MyTest;
use strict;
use warnings;
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::Server;
sub handler {
my $r = shift;
warn $r-server-server_name;
return 200;
}
1;
~
[Tue Feb 18 15:08:58 2003] [error] [client 192.168.0.33] Can't locate
object method server_name via package Apache::Server at
/home/nick/perl/NPT/MyTest.pm line 14.
- nick
--
Nick Tonkin {|8^)
Re: [mp2] $r-server-server_hostname() compatibility?
On Wed, 19 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
On Wed, 19 Feb 2003, Stas Bekman wrote:
Nick Tonkin wrote:
Does anyone know the equivalent directive for
$r-server()-server_hostname()
it's right there:
use Apache::Server;
$r-server-server_name;
oops, a typo, should be: $r-server-server_hostname
This and Apache::RequestUtil::get_server_name now seem to work jus' great.
- nick
--
Nick Tonkin {|8^)
[mp2] send_http_header() can't be called before the response phase
Hey,
I have a handler that is called like this:
Location /authenticate
sethandler perl-script
PerlHandler WM::Auth::Auth
/Location
the handler returns like this:
return logon_form($r);
logon_form starts like this:
sub logon_form {
my $r = shift;
$r-status(Apache::OK);
$r-content_type('text/html');
$r-send_http_header;
[...]
This throws the error:
send_http_header() can't be called before the response phase
Thanks,
- nick
--
Nick Tonkin {|8^)
Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I can't find
anything in any of the docs and even goggle groups only had one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
Re: What is lastest stable version of mod_perl? newbie question.
On Mon, 10 Feb 2003, Charlie Smith wrote:
What's the latest stable version of mod_perl?
Always available at http://perl.apache.org/download
I believe the latest stable version of Apache is 1.3.19, which is what I am
running.
No, the latest stable Apache version is 2.0.44. However, you should
probably get the stable 1.x version, 1.3.27, since mod_perl 2.x is not
really stable yet. See http://httpd.apache.org
I am at mod_perl version 1.25.
As I understand it, I need to recompile mod_perl with Apache 1.3.19 and perl
5.8 on sun box in order to get perl 5.8 (hitting an Oracle 9.0.1 database)
working with the mod_perl scripts.
PLEASE spend some time at http://perl.apache.org perusing the VERY
comprehensive and clear documentation. I am not aware that you _need_ perl
5.8 to compile the latest apache and mod_perl, but you might as well get
it now since you are upgrading those packages too. perl 5.6.1 eould also
be fine; perl 5.6.0 has problems.
HTH,
- nick
Nick Tonkin {|8^)
Re: [mp2] Apache::Request
On Fri, 31 Jan 2003, Lee Goddard wrote:
Does anyone know when this module might be released?
No, no one does. They are working on it. Use CGI.pm instead or revert to
mod_perl/apache version 1 until it is done.
- nick
Nick Tonkin {|8^)
Re: compiling mod_perl statically under FreeBSD
On Sun, 26 Jan 2003, [koi8-r] éÌØÑ ûÉÐÉÃÉÎ wrote:
Dear Sirs,
I tried to follow apaci/README, but I couldn't compile mod_perl statically
under FreeBSD.
can anybody tell me (step by step ?) how to compile statically
www/apache13-modssl + www/mod_perl ?
Thanks!
Ilia Chipitsine
Have you read the mod_perl guide? Especially
http://perl.apache.org/docs/1.0/guide/install.html#Installation_Scenarios_for_mod_perl_and_Other_Components
?
- nick
Nick Tonkin {|8^)
Re: [mp2]: Is there a package for Debian/testing?
On 23 Jan 2003, Joachim Zobel wrote:
Hi.
I would like to start testing mp2, but I remember that compiling
apache/mp1 was no fun at all.
FWIW it was much simpler and cleaner to install apache2 + mp2 than it ever
was with v1 in my case. Even when things went exactly as expected in v1
there were just more steps involved than now.
The two main things that have been simplified to the point of
disappearance are the build and install of SSL (mod_ssl is built into
apache core by default now) and the many arguments to mod_perl's perl
Makefile command.
Here's my build commands:
$ cd httpd-2.0
$ CC=gcc ./configure --prefix=/usr/local/apache --with-mpm=prefork --enable-ssl
--enable-info --enable-rewrite --enable-so
$ make make test make install
$ cd ../modperl-2.0
$ perl Makefile.PL MP_AP_PREFIX=/usr/local/apache MP_INST_APACHE2=1
$ make make test make install
This builds flawlessly on my system which is FreeBSD 4.7 and perl 5.8
I found one in debian unstable, but this requires perl 5.8.
I can't say about other perls, as I said I have 5.8
HTH
- nick
Nick Tonkin {|8^)
Re: mysql question
On Thu, 23 Jan 2003, Martin Moss wrote:
slightly off topic,
but is it possible to grant permissions to a user on multiple tables in one
sql statement in mysql?
This is not slightly off topic. It has nothing to do with mod_perl. You
are being selfish, rude and stupid. Especially since MySQL provides
excellent support.
Ask, can you block this bozo from the list?
- nick
Nick Tonkin {|8^)
Re: [mp2] e-Commerce
On Tue, 21 Jan 2003, Perrin Harkins wrote:
Eric Frazier wrote:
On that note, how about just using Apache2 for the proxy front end, and
mod_perl /apache 1.x for the back end? I have wanted to try to avoid the
thttpd stuff for images and from what I have heard about apache2 it can
handle static pages a lot faster than the 1.x did.
You really should be able to get more than enough performance out of 1.x
for static files, unless you are using very old hardware. We used a
slim 1.x build with mod_proxy, mod_ssl, and mod_rewrite for all of our
static files at eToys and it ran like a champ. It's true that both
thttpd and apache 2 have better performance, but web server performance
on static files is almost irrelevant on today's hardware because you
fill your bandwidth up long before anything else becomes an issue.
Hmm, I think it all depends on the application. It's true that hardware
costs have declined since The Days, but you still don't have unlimited
RAM. At ValueClick we were delivering 100 million+ gif images a day, after
doing all the hard stuff with mod_perl servers, and it was just not
possible to keep up with apache 1.3x. We wound up having just one machine
running thttpd serving all those images for 50 or a hundred webservers.
So sometimes I believe it's called for.
- nick
Nick Tonkin {|8^)
Re: [mp2] failed test building mp2
On Sun, 19 Jan 2003, Stas Bekman wrote:
Nick Tonkin wrote:
On Fri, 17 Jan 2003, Nick Tonkin wrote:
Hey all,
Building the latest mp2 I get:
protocol/echo_filter.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
apr/threadmutex.t33 100.00% 1-3
*** server localhost.rlnt.net:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
*** Error code 1
Nick et al, please submit a complete bug report as explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
(linked from the shortcuts menu!).
grumble
Hrmph. There should be a lynx-friendly version of these sites. All that
cool template-driven menu stuff just turns into a long long list of links!
/grumble
OK. Bug report sent under different mail, using latest cvs
sources. There's two errors now, used to be one!
Here is something to try with the prev error
Index: src/modules/perl/modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.50
diff -u -r1.50 modperl_util.c
--- src/modules/perl/modperl_util.c 11 Jan 2003 00:02:16 - 1.50
+++ src/modules/perl/modperl_util.c 19 Jan 2003 02:07:30 -
@@ -15,7 +15,7 @@
POPSTACK;
if (SvTRUE(ERRSV)) {
-if (logfailure) {
+if (1) {
(void)modperl_errsv(aTHX_ HTTP_INTERNAL_SERVER_ERROR,
NULL, NULL);
}
Patch made no difference to the error.
- nick
Nick Tonkin {|8^)
[mp2] make test errors w/. threadmutex, push_handlers
: SSLSessionCache]
[Sat Jan 18 21:23:02 2003] [info] Init: Initializing (virtual) servers for SSL
[Sat Jan 18 21:23:02 2003] [info] Server: Apache/2.0.43, Interface: mod_ssl/2.0.43,
Library: OpenSSL/0.9.6g END in
modperl_extra.pl, pid=9499
[Sat Jan 18 21:23:02 2003] [info] Init: Initializing OpenSSL library
[Sat Jan 18 21:23:02 2003] [info] Init: Seeding PRNG with 0 bytes of entropy
[Sat Jan 18 21:23:02 2003] [info] Init: Generating temporary RSA private keys
(512/1024 bits)
[Sat Jan 18 21:23:02 2003] [info] Init: Generating temporary DH parameters (512/1024
bits)
[Sat Jan 18 21:23:02 2003] [info] Init: Initializing (virtual) servers for SSL
[Sat Jan 18 21:23:02 2003] [info] Server: Apache/2.0.43, Interface: mod_ssl/2.0.43,
Library: OpenSSL/0.9.6g
[Sat Jan 18 21:23:02 2003] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_09-dev
Perl/v5.8.0 mod_ssl/2.0.43 OpenSSL/0.9.6g
configured -- resuming normal operations
[Sat Jan 18 21:23:02 2003] [info] Server built: Jan 17 2003 19:14:32
[Sat Jan 18 21:23:02 2003] [debug] prefork.c(1039): AcceptMutex: flock (default: flock)
[Sat Jan 18 21:23:03 2003] [error] server reached MaxClients setting, consider raising
the MaxClients setting
[Sat Jan 18 21:23:09 2003] [info] [client 127.0.0.1] TestAPI::aplog test in progress
[Sat Jan 18 21:23:09 2003] [debug]
/home/tmp/build/modperl-2.0/t/response/TestAPI/aplog.pm(43): log_serror
test ok
[Sat Jan 18 21:23:09 2003] [debug]
/home/tmp/build/modperl-2.0/t/response/TestAPI/aplog.pm(46): (20007)Notime was
provided and one was required.: log_serror test 2 ok
[Sat Jan 18 21:23:09 2003] [debug]
/home/tmp/build/modperl-2.0/t/response/TestAPI/aplog.pm(49): [client 127.0.0.1]
(20007)No time was provided and one was required.: log_rerror
test ok
[Sat Jan 18 21:23:09 2003] [error] $r-log_error test ok
[Sat Jan 18 21:23:09 2003] [error] $s-log_error test ok
[Sat Jan 18 21:23:09 2003] [debug]
/home/tmp/build/modperl-2.0/t/response/TestAPI/aplog.pm(63): TestAPI::aplog
test done
[Sat Jan 18 21:23:09 2003] [warn] ApacheApache-warn test ok
[Sat Jan 18 21:23:09 2003] [warn] $s-warn test ok
[Sat Jan 18 21:23:17 2003] [error] [client 127.0.0.1] Can't locate
APR/ThreadMutex.pm in @INC (@INC contains: /home/tmp/build/modperl-2.0/t
/home/tmp/build/modperl-2.0/blib/lib/Apache2
/home/tmp/build/modperl-2.0/blib/arch/Apache2
/home/perl/lib/site_perl/5.8.0/i386-freebsd/Apache2
/home/tmp/build/modperl-2.0/Apache-Test/lib
/home/tmp/build/modperl-2.0/lib /home/tmp/build/modperl-2.0/blib/lib
/home/tmp/build/modperl-2.0/blib/arch
/home/tmp/build/modperl-2.0/t/response
/home/tmp/build/modperl-2.0/t/protocol /home/tmp/build/modperl-2.0/t/hooks
/home/tmp/build/modperl-2.0/t/filter
/home/tmp/build/modperl-2.0/t/htdocs/testdirective/perlmodule-vh
/home/tmp/build/modperl-2.0/t/htdocs/testdirective/main /home/nick/perl
/home/perl/lib/5.8.0/i386-freebsd /home/perl/lib/5.8.0
/home/perl/lib/site_perl/5.8.0/i386-freebsd /home/perl/lib/site_perl/5.8.0
/home/perl/lib/site_perl) at
/home/tmp/build/modperl-2.0/t/response/TestAPR/threadmutex.pm line 17.
[Sat Jan 18 21:23:18 2003] [error] Apache::log_error test ok
[Sat Jan 18 21:23:27 2003] [error] [client 127.0.0.1] File does not exist:
/home/tmp/build/modperl-2.0/t/htdocs/TestError::push_handlers
FILTER READ: 1024 bytes
[Sat Jan 18 21:23:35 2003] [error] [client 127.0.0.1] File does not exist:
/home/tmp/build/modperl-2.0/t/htdocs/nope
[Sat Jan 18 21:23:40 2003] [error] [client 127.0.0.1] need AuthName:
/TestModperl::setauth
[Sat Jan 18 21:23:44 2003] [info] removed PID file
/home/tmp/build/modperl-2.0/t/logs/httpd.pid (pid=9500)
[Sat Jan 18 21:23:44 2003] [notice] caught SIGTERM, shutting down
END in modperl_extra.pl, pid=9500
- nick
Nick Tonkin {|8^)
[mp2] Conflicting instructions in docs?
Well, I'm taking the plunge.
I have a brand new spiffy machine I'm configuring and I've decided, since
for once I don't have to get it up and running urgently, to go the whole
hog and move to the 2.0 world.
For me this means upgrading not only from apache 1.3x and mod_perl 1.2x
but also from perl 5.005.
I'm going to install 5.8 but am confused by an apparent contradiction in
the mod_perl2 docs.
In http://perl.apache.org/docs/2.0/user/install/install.html it first
says:
Remember that threads support slows things down, so don't enable it unless
you really need it.
But then under 'Configuring and Installing Prerequisites' it gives an an
example:
% ./Configure -des -Dusethreads
I'm confused. Where's the quick answer to whether or not I should use
threads? I'm on FreeBSD 4.7.
Thanks,
- nick
Nick Tonkin {|8^)
Re: [mp2] Conflicting instructions in docs?
On Sat, 18 Jan 2003, Stas Bekman wrote:
Nick Tonkin wrote:
Well, I'm taking the plunge.
I have a brand new spiffy machine I'm configuring and I've decided, since
for once I don't have to get it up and running urgently, to go the whole
hog and move to the 2.0 world.
For me this means upgrading not only from apache 1.3x and mod_perl 1.2x
but also from perl 5.005.
I'm going to install 5.8 but am confused by an apparent contradiction in
the mod_perl2 docs.
In http://perl.apache.org/docs/2.0/user/install/install.html it first
says:
Remember that threads support slows things down, so don't enable it unless
you really need it.
But then under 'Configuring and Installing Prerequisites' it gives an an
example:
% ./Configure -des -Dusethreads
I'm confused. Where's the quick answer to whether or not I should use
threads? I'm on FreeBSD 4.7.
As Geoff has replied, plus it's documented:
http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites
I'll change the example to have both ways demonstrated.
That would help remove the perception of a suggestion towards
threading. But what I was really looking for was something to help me
choose whether or not to use threads at all. I couldn't find this clear
answer in the perl documentation. Geoff suggested that if stability was a
priority and performance was not, particularly, then I might as well stay
away from threads both in apache and in perl. Later I found a tip for
installing apache2 for FreeBSD (in the apache docs) that warned against
using threads on FreeBSD in any event. So I made what seems now to be an
obvious decision to not use 'em.
But I think it would be better if the pointer you _do_ have in the docs,
which I quoted, saying that threqads should be avoided unless there's a
really good reason why not, could be emphasized or clarified more.
- nick
Nick Tonkin {|8^)
Re: [mp2] Conflicting instructions in docs?
On Sat, 18 Jan 2003, Stas Bekman wrote:
See if it's any better now. Go to:
http://perl.apache.org/docs/2.0/user/install/install.html#Configuring_and_Installing_Prerequisites
which takes you to:
http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites
which mentions all the probs in the prefork mpm section. Obviously the
threaded-mpm requires threads.
Looks better to me. More clear.
-nick
Nick Tonkin {|8^)
[mp2] failed test building mp2
Hey all,
Building the latest mp2 I get:
protocol/echo_filter.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
apr/threadmutex.t33 100.00% 1-3
*** server localhost.rlnt.net:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
*** Error code 1
Stop in /home/tmp/build/mod_perl-1.99_08.
the error_log says:
[Fri Jan 17 20:03:33 2003] [error] Apache::log_error test ok
[Fri Jan 17 20:03:46 2003] [error] [client 127.0.0.1] File does not
exist: /home/tmp/build/mod_perl-1.99_08/t/htdocs/nope
[Fri Jan 17 20:03:51 2003] [error] [client 127.0.0.1] need
AuthName: /TestModperl::setauth
[Fri Jan 17 20:03:55 2003] [info] removed PID file
/home/tmp/build/mod_perl-1.99_08/t/logs/httpd.pid (pid=62235)
[Fri Jan 17 20:03:55 2003] [notice] caught SIGTERM, shutting down
END in modperl_extra.pl, pid=62235
I have perl 5.8 on FreeBSD 4.7 with latest apache2 as of today.
Thanks,
- nick
Nick Tonkin {|8^)
Re: [mp2] failed test building mp2
On Fri, 17 Jan 2003, Nick Tonkin wrote:
Hey all,
Building the latest mp2 I get:
protocol/echo_filter.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
apr/threadmutex.t33 100.00% 1-3
*** server localhost.rlnt.net:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
*** Error code 1
The perl error was that APR/ThreadMutex.pm was not found. But it's right
next to everything else.
I changed the 'require APR::ThreadMutex' to 'use APR::ThreadMutex'
(outside the handler() sub) anow test suite skips the threadmutex.pm test.
What does this mean?
- nick
Nick Tonkin {|8^)
Re: cgi-script to handler communication [MP2]
Umm, sanity check: You _have_ checked out the many packages and modules
that do just this under mod_perl, haven't you?
On 16 Jan 2003, Vishal Verma wrote:
Though it's probably not as fast as adjusting the headers via the api in
the response handlers. However since you aren't telling what you are
trying to do I can't give you a better advice.
Here's what I'm trying to do:
I am implementing a login/logout mechanism. The user can't access any
page till he logs in. That is any attempt to access pages without
logging in will be redirected to the login screen. I have successfully
implemented this part. The login page is generated by a CGI script. Once
the user logs in successfully, I want to set a cookie. That's the reason
why I want the login CGI script to pass the result to my handler. The
handler, which must be run after the CGI script has been run, will
decide to modify the output header (to set cookie) depending upon the
result code passed to it by the login screen.
I have read all the documentation about handlers etc., and couldn't find
a way to do this. I know about notes/pnotes, but aren't they for passing
values from one handler to other. How can my CGI script use them? And if
it is possible for my CGI script to use them, would that be safe when
multiple users are trying to log in?
One more question. I redirect the incoming request by calling
$r-uri($new_uri) in my PerlTransHandler. How can I make the browser
show this new location in its address bar?
Let me know if you need to know more about any aspect of my
implementation. And, thanks for your help.
-vish
- nick
Nick Tonkin {|8^)
Re: Redirect or Subprocess - Problems
On Mon, 13 Jan 2003, Marc Ian Brewer wrote:
Hi everybody,
I have a problem with Mod_Perl 1.27 on Apache 1.3.12. We have an Perl
Transaction Handler which takes all requests. The Transaction Handler
is only for redirecting to different pages. One of this pages is an
embedded Perl page.
Our problem is, that one request will be proceed more then 3 times
from the transaction handler. After that the results will be
displayed. So we will have awful performance problems.
Our archivtecture is like this :
--Request- Perl Transaction Handler (4 or more
times)--- Content Display By Embedded Perl
-- Response
Has someone an idea to solve this problem ???
You do not make your problem very clear. What is performance
problems? If you mean that the httpd hangs around for a long time waiting
for the other processes to end, and thus your web server gets bogged down,
than you should look at setting up a thin front-end apache with the
mod_perl server behind. That's the subject of a good deal of info in the
mod_perl Guide and in the archives of this list.
- nick
Nick Tonkin {|8^)
Re: Load balancers
On Mon, 13 Jan 2003, John Siracusa wrote:
But meanwhile, we're still open to alternatives. Surprisingly, there don't
seem to be many (software) options. (A hardware load balancer is not an
option at his time, but I'll also take any suggestions in that area :)
My experience in this area led quickly to the conclusion that there is no
viable software solution, at least when you get a bit of traffic.
We quickly moved to hardware load balancing and did very well with the
Coyote Point Equalizer, which was affordable and powerful. Also the
developers (Bill Kish is/was the lead developer) were very responsive and
worked with us to tweak as necessary.
After a while we got one of those loser CFOs who was golf pals with the
new COO or something, and he bought a bunch of Foundry Systems Server
Irons that worked alright but were orders of magnitude more expensive.
- nick
Nick Tonkin {|8^)
RE: Load balancers
On Mon, 13 Jan 2003, Jesse Erlbaum wrote:
Hi John --
That's for all the info so far. To answer some questions,
hardware is a cost issue right now. It's somewhat scary that
$3,200 was a reasonable price several years ago, but I
suppose it could be worse. We will investigate further.
Actually, $3200 was a STEAL! Cisco's Local Director was in the mid
five-figures at the time, IIRC. :-)
So it was that range, not $15K as I thought. Yep, I remember that we got
both of them for far far less than a Cisco, and much better support. We
had the chief developer's cell phone number, and he would help us out all
the time. At the time we were growing so fast we were almost a test case
for them ... we took them up to at least 70 million dynamic requests a
day, with stickiness required, using the adaptive balancing, with no real
problems, before moving to the Foundry Systems hardware.
- nick
Nick Tonkin {|8^)
Re: [modperl 1.27] Problem regarding Perl*Handler and the HTTPrequest line
On Tue, 24 Dec 2002 [EMAIL PROTECTED] wrote: Hi all Apologise if I have posted to the wrong list. I am quite new to the Perl*Handlers. I am wondering if it is possible to write a handler which parses the very first header line, say.. telnet localhost http Trying 127.0.0.1 Connected to localhost. Escape character is '^]' [C] THIS_IS_NOT_A_USUAL_HTTP_HEADER\r\n [S] YOUR_REQUEST_IS_UNDERSTOOD,_SEND_MORE_DETAIL\r\n [C] Other: non-usual-http-headers-here\r\n [S] balbalbal..closing connection\r\n Connection closed by remote host. where the line followed by [C] stands for the line sent by the client, and the line followed by [S] is the line sent by some perl module. I would like to have the other GET/POST requests being processed like any other server does (i.e. if the request line is a usual GET/POST line, the handler bypasses it, otherwise the handler will make apache 'sends' the request to another perl module that knows how to handle this request). If all you want to do is handle certain requests in a special manner, and you are able to have control over the requests, why do you not use a simpler scheme, such as directing them to a different port, or, better yet, a different URI? If you are getting the requests from a browser it will be difficult anyway to add custom headers, I think. But if you can control the request you can easily have http://your.server.com/path/to/resource/special http://your.server.com/path/to/resource or something similar, and have a handler that handles everything in that path, returning DECLINED if it doesn't match the URI you are looking for (you don't need two handlers for this). Hope this helps, - nick
Re: mod_perl fails tests
On Wed, 18 Dec 2002 [EMAIL PROTECTED] wrote:
Yes, I was able to find CGI.pm.
You may have found it but your webserver hasn't.
Do you know how I can fix my problem and
get mod_perl installed and configured.
You need to fix this part first.
I would try unintsalling and then reinstalling CGI.pm via CPAN.
- nick
Nick Tonkin {|8^)
Thanks-
Rodney
On Wed, 18 Dec 2002 16:13:19 +0800 Stas Bekman [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I am having some trouble installing mod_perl
on my redhat linux 8.0 box. I
successfully installed apache 2.0.43 from
source and placed it in the
/usr/local/apache2 directory. In addition, I
downloaded the latest version of
mod_perl from cvs. I successfully used the
following command to generate the
makefile: perl Makefile.PL
MP_AP_PREFIX=/usr/local/apache2
MP_INST_APACHE2=1.
Even though the make process was successful
the make test process was not. As
clear as I can tell from the error message
that I listed below, mod_perl is
looking for apache components in
/home/software/apache_cvs/modperl-2.0/t/conf/httpd
.conf which is clearly
wrong since my httpd.conf file is in
/usr/local/apache2/conf.
Actually, this is the correct httpd.conf which
is autogenerated for the
tests only
Here is the error message:
waiting for server to start: ...[Tue Dec 17
17:37:17 2002] [info] 19 Apache::
modules loaded
[Tue Dec 17 17:37:17 2002] [info] 5 APR::
modules loaded
[Tue Dec 17 17:37:17 2002] [info] base server
+ 6 vhosts ready to run tests
..[Tue Dec 17 17:37:19 2002] [info] 19
Apache:: modules loaded
[Tue Dec 17 17:37:20 2002] [info] 5 APR::
modules loaded
.[Tue Dec 17 17:37:20 2002] [info] base
server + 6 vhosts ready to run tests
Syntax error on line 693 of
/home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf:
Can't locate CGI.pm in @INC (@INC contains:
/home/software/apache_cvs/modperl-2.0/blib/lib/Apache2
/home/software/apache_cvs/modperl-2.0/blib/arch/Apache2
/home/software/apache_cvs/modperl-2.0/Apache-Test/lib
/home/software/apache_cvs/modperl-2.0/lib
/home/software/apache_cvs/modperl-2.0/blib/lib
/home/software/apache_cvs/modperl-2.0/blib/arch
/home/software/apache_cvs/modperl-2.0/t/response
/home/software/apache_cvs/modperl-2.0/t/protocol
/home/software/apache_cvs/modperl-2.0/t/hooks
/home/software/apache_cvs/modperl-2.0/t/filter
/home/software/apache_cvs/modperl-2.0/t
/home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh
/home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl) at (eval 22) line
3.
!!!
server has died with status 255
(t/logs/error_log wasn't created, start the
server in the debug mode)
make: *** [run_tests] Error 143
You mean, you have 5.8.0 but no CGI.pm? It
should be there, because it's
the part of the core.
can you please do:
find /usr/lib/perl5 -name CGI.pm
Do you get it?
__
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: What's On-topic and what's Off-topic on this list
One thing that's useful for both people who don't know where else to turn
and people who don't want anything that's not pure mod_perl is simply to
preface your subject line with [OT] ... it's then very simple to filter
out unwanted messages in any mail reader.
- nick
PS Stas, I think maybe you meant to s/brag/ramble/g ... one thing I've
never seen you guilty of is bragging :)
Nick Tonkin {|8^)
On Tue, 17 Dec 2002, Stas Bekman wrote:
I've the feeling that many subscribers are quite confused about the
on-topic/off-topic policy on this list.
In general, we try to keep threads mod_perl-centric. Because when the list
starts to be dumping grounds for other related things, with a side effect of
surging the list's traffic, those who were interested in pure mod_perl
discussions, simply leave. And among those who leave we lose current or
potential contributors.
It's extremely hard to tell what's on-topic and what's not, because mod_perl
programmers touch an enourmous amount of areas at their work. And sometimes
this list is the only place where you can get an advice on certain topics,
which happen to be related to mod_perl. But... my rule of thumb of deciding
what's off-topic is very simple: think whether there is another good place to
discuss a question in hand.
May be an example will help to explain that approach.
If somebody asks a beginners question on perl; usually how to write their code
better, or why some code doesn't work, you have to agree that there are plenty
other forums where this can be discussed (e.g. perlmonks.org). Now, when
somebody asks about a proper way to generate unique hardly guessable session
keys, that's a grey zone; on one side this is not a mod_perl specific
question, on the other side it is, because under mod_perl you can take a
benefit of process persistance and the way your keys are generated are a bit
different. If you ask about performance improvement, this is kind of questions
that are always welcome here, because I doubt there is any other forum where
there are as many experts in performance as in the mod_perl community. But
again, this is a grey zone. Obviously when something doesn't work under
mod_perl, but works under mod_cgi, this is a very ontopic question.
So, the next time you are about to ask a question which is not clearly on
topic, first think whether you can get your answers elsewhere. If you don't
where to ask, and you have browsed the help docs, ask about the right resource
(just like Jeff did). If you have failed to find an answer elsewhere, after
truly looking for it, I guess it's fine to ask here as a last resort,
explaining your situation. But some people dare to post a statement: I know
that you can answer my question, so I'm asking it here. That's ugly.
I feel that we need to add some sort of explanation of the on/off-topic posts
issue to http://perl.apache.org/maillist/email-etiquette.html. Perhaps
somebody who's writing is better than mine can contribute that. I feel that I
brag too much around and people lose the point. So if somebody can write a
clear, concise version of my bragging, or even better your own thoughts,
please do that.
Finally, it's everybody's list. If you don't like the way things are, change
them. But please don't complain if you do nothing to help others (that's
unrelated to your post, Jeff :).
__
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: Perl Cookbook modperl chapter
Nat,
Obviously you (or ORA) _are_ competing with mod_perl Developer's
Cookbook ...
If ORA wanted to cover mod_perl they should not have let Geoff co. get
away to another publisher.
Trying now to cover highly complex topics like Authenticating in
mod_perl in a recipe in a chapter of the Perl cookbook is futile. It will
only serve to oversimplify and lead novices into a false sense of
competence. They'll then show up on this list demanding to know why their
hacks on your recipes do not function as expected.
I do not believe you will do any service to mod_perl or to your readers by
glossing over how large a field of study mod_perl is. It's almost as bad
as the Teach Yourself Perl in 24 Hours title put out by Geoff's
publisher.
I urge you to rethink this plan.
- nick
Nick Tonkin {|8^)
On Wed, 11 Dec 2002, Nathan Torkington wrote:
I need some people with brains (instead of the warm gray mush filling
my head, the effects of becoming an editor) to look over the first 1/3
or so of a mod_perl chapter for the upcoming Perl Cookbook. I need
people to read the work for accuracy. If you're interested, send me
mail: [EMAIL PROTECTED].
I also need help on content. I'm not competing with Geoff, Randy, and
Paul's excellent book (mod_perl Developer's Cookbook)--they have 630
pages to cover way more topics than I do. Their book will always be
the definitive place for a hard-core mod_perl developer to go--in
fact, I'll have them in the See Also sections of the Perl Cookbook.
But I need to cover 15-20 topics that most people of beginning to
intermediate mod_perl use will encounter.
Current recipe list:
[gnat:~] grep head1 Ora/pcb2/ch21.pod
=head1 Introduction
=head1 Authenticating in mod_perl
=head1 Setting Cookies in mod_perl
=head1 Accessing Cookie Values from mod_perl
=head1 Redirecting the Browser from mod_perl
=head1 Interrogating Headers in mod_perl Handlers
=head1 Accessing Form Parameters from mod_perl
=head1 Receiving Uploaded Files in mod_perl
All suggestions appreciated.
Thanks,
Nat
Re: Perl Cookbook modperl chapter
On Wed, 11 Dec 2002, Nathan Torkington wrote:
Actually, we do cover mod_perl--we published the Eagle book, Writing
Apache Modules ... way back in 1999.
Yes, I have had my now dog-eared copy since then :)
There's no way that 20 recipes in the Perl Cookbook will compete with
the what, 250? in the mod_perl Developer's Cookbook. Especially when
the introduction and each recipe points the reader to the mpDC. The
Perl Cookbook has over a hundred thousand readers. I want to push as
many as I can onto the mpDC. If that's competing, then I can only say
that you have a strange sense of competition :-)
Ahem, well, without wanting to get into a fruitless argument about this
part, I might say that you have a strange idea of how to push people onto
their book. At close to $50 a pop, I know I'd think twice about purchasing
the mpDC if I'd shelled out for the Perl Cookbook and it had a section on
mod_perl. I venture to say Geoff et al will see less overall sales, rather
than more, if the PCB has a mod_perl section. This notwithstanding the
fact that _some_ people _will_ no doubt have their appetite whetted and
move on to the definitive mpDC. (Of course there's nothing definitive
about Perl, that's the whole point about TMTOWTDI, right?)
Trying now to cover highly complex topics like Authenticating in
mod_perl in a recipe in a chapter of the Perl cookbook is
futile. It will only serve to oversimplify and lead novices into a
false sense of competence.
This was really my point.
The Perl Cookbook has never pretended to be the definitive guide to
anything it covers (have you seen the Perl Cookbook? I recommend
it :-). Each recipe includes references to definitive sources of
information (manpages, web sites, and other books).
I have also owned the Perl Cookbook since it came out. It's very useful as
exactly what it says: a cookbook. You can turn to it for a recipe to
accomplish a small, simple task which you guess others may have tackled
before you. You can also use it as a tutorial, if you choose to, by
studying each chapter as a whole. I do not believe that mod_perl lends
itself to the former, and I think that the mpDC more approaches the
latter. One can go look up a recipe, true, but it is useless without a
pretty thorough prior understanding of mod_perl. So, I stand by my
prediction that just putting a few mod_perl recipes in the PCB will lead
more than a few people into more problems than solutions.
While I've been writing this reply a few people have responded to your
request for content suggestions. Stacked handlers, among other things
... I think it just goes to show that there can be no successful trivial
coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so
good.)
- nick
Nick Tonkin {|8^)
Re: Apache logging phase
Not a mod_perl issue; in your apache conf do this:
# I keep all images and javascripts etc under /_[something]
SetEnvIf Request_URI /_ dontlog
CustomLog /home/nick/logs/httpdlog common env=!dontlog
- nick
Nick Tonkin {|8^)
On Tue, 19 Nov 2002, Cure wrote:
I'm curious -- is there a way in mod_perl to skip
the apache logging phase for certain directory or script request ?
Cure
[OT] Wanted: beginning perl books for poor kids
Hi all,
I am going to be working with a small group of disadvantaged youngsters
here teaching them how to build web applications with perl and
apache.
These are mostly Latino kids who have been doing analog and digital art
for years and have self-selected into webmastering, html-ing and such.
I'm excited to get them going in perl, and I want to appeal to the list
for donations of books on learning perl.
Of course I'm most hopeful that we can get half a dozen copies of the
Llama book and use it as a sort of textbook, but anything will be
gratefully accepted.
An existing site that shows some of the art these kids make (and also
why we need a new one!) can be viewed at http://www.rain.org/~artworks/
A cool project by one of the students is at
http://www.rain.org/%7Eartworks/NewATW/students/norma_web/norma_intro.html
Thanks folks,
- nick
Nick Tonkin {|8^)
Re: How would you organize custom logging?
On Thu, 10 Oct 2002, Ged Haywood wrote:
Hi there,
On Thu, 10 Oct 2002, Marcin Kasperski wrote:
I am to provide some custom logging in my mod_perl application.
[snip]
and On Thu, 10 Oct 2002, Victor Tsang wrote:
Instead of developing something new, how about extending the
combined/common log format?
Or you could investigate the various logging modules already in
existence. Look in the mod-perl Cookbook chapters 16, the Eagle Book,
the Guide (see the mod_perl home page for details) and on CPAN.
how should I pass data between handlers - just stick to some perl
global variable or use pnotes?
See for example 8.11 in the Cookbook.
3) Are there any tools of 'gather logs from multiple machines to the
central location' you would recommend?
The database approach would probably be easiest.
Easy but totally unscalable unless you make it not easy, with caching,
cache flushing to account for network hiccups, etc. etc.
Eventually we wrote a system with a logging daemon on the server and
clients on the clients. The latter took logging data from apache with a
custom handler and then sent it off to the daemon using some of the
techniques I mentioned above.
- nick
Nick Tonkin {|8^)
Re: Change in module naming conventions
- nick
Nick Tonkin {|8^)
On Tue, 27 Aug 2002, Per Einar Ellefsen wrote:
- I originally had Apache::Auth::Authen, ::Authz and ::Access, but Robin
Berjon told me he preferred to have the 4 as top-level namespaces. What do
people think?
I'm in favor of your approach. I have it like that in my
stuff. Auth::Auth, Auth::Authz, and Auth:: Access.
- nick
Nick Tonkin {|8^)
Re: ANNOUNCE: the new perl.apache.org is alive now!
The content seems great. But whatever font you've used is rendering skinny
and pixelated and hard to read and makes me want to egt of the site
asap ... why not leave font face undetermined so the font that each has
chosen for his platform is employed?
- nick
Nick Tonkin {|8^)
Re: [OT] Better Linux server platform: Redhat or SuSe?
I'm confused. Since when did bloat surpass elegance as a measure of
success in Perl programming?
- nick
Nick Tonkin {|8^)
On Thu, 4 Jul 2002 [EMAIL PROTECTED] wrote:
On Wed, Jul 03, 2002 at 02:41:38PM +0100, Peter Haworth wrote:
On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote:
perl: Any iussues with perl/modperl? Besides modperl I will be running a
perl application with a few hundred thousend lines of code...
Wow. For reference last time I looked at slashcode it was about 25.000
lines I think. I wonder what kind of application would require more than
that amount of Perl code :-)
I'm sure someone else will post a bigger number, but my application (IOP
Electronic Journals) has 55000 lines of code (including the odd blank line
and comment, of course). And we're always adding new stuff, so it only ever
gets bigger.
Schoolmaster.net, 167,000 lines of Perl code, another 30,000 lines of C.
Rich.
--
[EMAIL PROTECTED] | Is your school part of http://www.schoolmaster.net ?
BiblioTech Ltd, Unit 2 Piper Centre, 50 Carnwath Road, London, SW6 3EG.
+44 20 7384 6917 | Free software: http://freshmeat.net/users/rwmj
Copyright © 2002 Richard Jones | GnuPG/PGP key from www.annexia.org
Re: Strange Apache 2.0 rewrite/proxy issue
On 4 Jan 2002, Vivek Khera wrote:
JA == John Armstrong [EMAIL PROTECTED] writes:
JA Because the front end reverse proxy needs to connect to one of 3
JA different servers.
JA 1) Static html server.
I always make my front end reverse proxy handle static content
directly.
Always is a strong word! At ValueClick we used thttpd servers to deliver
gif images ... one thttpd could efficiently handle the same number of
requests as several (non-mod_perl) front end reverse proxies ...
- nick
Nick Tonkin {|8^)
Re: Fast template system
Yeah, TT is good, all right, especially with the ability to change the
start and end tags to something more compliant, like !-- and --.
Uh ... why aren't you syntax-validating the actual HTML output by your
application?
Also, there are multiple syntax-checkerts that allow you to specify
validation rules.
I'd gladly switch, if someone knows how to get it working on FreeBSD
-STABLE without breaking everything else :-)
Quit using FreeBSD ports. Compile from source. Your problem is almost
certainly due to FreeBSD's weird installation of Perl, specifically its
library paths.
The best solution I've found is to create a new user 'perl' and install
Perl and all libraries etc under that user's home directory.
My system:
nick@world ~uname -a
FreeBSD world.tonkinresolutions.com 4.4-PRERELEASE FreeBSD 4.4-PRERELEASE
#1: Sat Aug 11 18:17:44 PDT 2001
[...]
nick@world ~perl -v
This is perl, version 5.005_03 built for i386-freebsd
[...]
nick@world ~perl -MTemplate -e 'print $Template::VERSION,\n'
2.06
- nick
Nick Tonkin {|8^)
Re: load balancing on apache
You should also check out Coyote Point's Equalizer ... this a
hardware/software solution that worked well for ValueClick up to about 70
million requests per day. It's basically a FreeBSD box with a custom
dynamic natd ... supports hot-swap redundancy with two of 'em installed
... and a _lot_ cheaper than LocalDirector and others (although we did
move to a high-end Foundry Server Iron system eventually) ... good support
from a small company too.
- nick
Nick Tonkin {|8^)
On Fri, 14 Dec 2001, Perrin Harkins wrote:
I am planning to host an application and its size is going to be big one ,
so expect the concurrent number of connection s to be around 2200.
To combat the same , want to perform load sharing on 3-4 servers.
If you really expect 2200 concurrent connections, you should buy dedicated
load-balancing hardware like Big/IP or Cisco LocalDirector.
- Perrin
Re: Deleting a cookie
Expiring the cookie works well for me. Here's what I have:
sub handler {
[ ... ]
if ($r-uri =~ /logout/) {
if (my $cookie = destroy_cookie($r)) {
return logout_screen($r);
} else {
return 500;
}
}
[ ... ]
}
sub destroy_cookie {
my $r = shift;
# you may or may not be using this
my $auth_domain = $r-dir_config('Auth_Domain');
my $cookie = Apache::Cookie-new(
$r,
expires = -24h,
domain = $auth_domain,
name= 'auth', # whatever you've called it
path= '/',
value = ''
);
$cookie-bake;
return $cookie;
}
sub logout_screen {
[ ... ]
}
1;
~~~
Nick Tonkin
On Tue, 27 Nov 2001, Jon Robison wrote:
I have created a login system using the wonderful Ticket system from the
Eagle book. I have modified TicketAccess so that after authentication,
it reviews the arguments in the query string and does push_handler, the
handler being chosen based on the args.
My only problem is that I want to provide the users with a logout button
which will delete the cookie from thier browser, yet I cannot find how!.
I have reviewed every module on my system with 'Cookie' in the name
(Apache::Cookie, CGI::Cookie, etc.) and nowhere does it tell how to do
this. There is a small mention of changing the expiration to 0, but
apparently I am doing it wrong (possible confusing point is the use of
an 'expires' value in the cookie itself, seperate, I think, from the
'expires' attribute on the cookie?)
I know it is a lot to ask, but I am relatively new to this part of
mod_perl (pushing handlers, etc.), so if anyone can look at this and
replace my BLOCKED comments with a couple of helpfull lines, I would
greatly appreciate it!
Thanks in advance -
Jonathon Robison
Below is my modified TicketAccess, as well as the Logout module I am
re-directing to for logout action:
=
package FES::Apache::TicketAccess;
use strict;
use Apache::Constants qw(:common);
use FES::Apache::TicketTool ();
sub handler {
my $r = shift;
my %input = $r-args;
# for checking input items
my $ticketTool = FES::Apache::TicketTool-new($r);
my($result, $msg) = $ticketTool-verify_ticket($r);
unless ($result) {
$r-log_reason($msg, $r-filename);
my $cookie = $ticketTool-make_return_address($r);
$r-err_headers_out-add('Set-Cookie' = $cookie);
return FORBIDDEN;
}
## Here is where we need to insert a push_handler insert. I won't need
## the requested uri from the $r, since the $r goes along for the ride
in## push_handler
my $action = defined $input{'act'} ? $input{'act'} : 'view';
print STDERR action is defined as $action\n; ## DEBUGGING
if ($action eq 'logout') {
$r-push_handlers('PerlHandler' = 'FES::Control::Logout');
return OK;
} elsif ($action eq 'view') {
$r-push_handlers('PerlHandler' = 'FES::Control::View');
return OK;
} else {
$r-push_handlers('PerlHandler' = 'FES::Control::View');
return OK;
}
## ARE THOSE THE CORRECT THINGS TO 'RETURN' FOR THESE CASES?
}
1;
==
And the Logout.pm:
=
package FES::Control::Logout;
use strict;
use Apache;
use Apache::Constants qw(:common);
use FES::Common::Common qw( header footer);
use CGI qw/:standard/;
use CGI::Cookie;
sub handler {
my $r = shift;
my $q = new CGI;
my $ticket = _get_ticket('r' = $r);
## HERE IS WHERE I NEED TO 1.) DELETE USER'S TICKET COOKIE AND
## 2.) REDIRECT THEM TO /FES (w/o bringing old
$r),(WHERE THEY SHOULD GET
## A NEW LOGIN SCREEN BECAUSE COOKIE IS
GONE.)
}
sub _get_ticket {
my $args = {
'r' = undef,
@_
};
my $r = $args-{'r'};
my %cookies = CGI::Cookie-parse($r-header_in('Cookie'));
# TESTING
my %ticket = $cookies{'Ticket'}-value; # TESTING
return \%ticket;
}
1;
=
[OT] Re: search.cpan.org
Because it does a full text search of all the contents of the DB. ~~~ Nick Tonkin On Tue, 27 Nov 2001, Robert Landrum wrote: Does anyone know why search.cpan.org is always the s-l-o-w-e-s-t site on the internet? I can't believe it always busy. I've had trouble hitting it at 3 AM. Maybe it's just me... Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
[OT] Re: search.cpan.org
Well, ask Ask if you want the whole truth. But when I saked him that's what he said. Maybe there's a problem with the architecture and some pre-indexing is done per session or something suboptimal like that. Ask? ~~~ Nick Tonkin On Tue, 27 Nov 2001, Robert Landrum wrote: Sure... When doing searches. But it takes me about 20 seconds just to hit any page... not just the search pages. And don't misunderstand, I think search.cpan.org is awesome. I just wondered if anyone knew why it was slow all the time. Rob At 12:55 PM -0800 11/27/01, Nick Tonkin wrote: Because it does a full text search of all the contents of the DB. ~~~ Nick Tonkin On Tue, 27 Nov 2001, Robert Landrum wrote: Does anyone know why search.cpan.org is always the s-l-o-w-e-s-t site on the internet? I can't believe it always busy. I've had trouble hitting it at 3 AM. Maybe it's just me... Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
[OT] Re: How to create a browser popup window
Off topic but in the interests of, if not less popup windows, then at
least less broken ones:
You must include code to deal with the fact that you may have already
opened a popup window. Something like this:
SCRIPT LANGUAGE=JavaScript
!-- Hide
var popupwin = null;
function popup(loc,ww,hh) {
var mywidth = (ww + 10);
var myheight = (hh + 10);
var myspecs =
'menubar=1,status=1,resizable=1,location=1,titlebar=1,toolbar=1,scrollbars=1,width=
+ mywidth + ,height= + myheight + ';
if (popupwin == null || popupwin.closed) {
popupwin = window.open (loc, 'popupwin', myspecs);
} else {
popupwin.close();
popupwin = window.open (loc, 'popupwin', myspecs);
// If all your windows should be the same
// size then comment out the above two lines and
// uncomment the next two lines
// popupwin.focus();
// popupwin.location.href = loc;
}
}
/SCRIPT
A HREF='javascript://' onClick='popup(foo.gif,300,200); 'Look at foo/A
This one is good for calling with just an image as the href. You can use
any code you like, including the other example posted here. Just remember
to test whether you already have the window open or not and act
appropriately.
~~~
Nick Tonkin
On Tue, 20 Nov 2001, Ben Demonte wrote:
How to create a browser popup windowhow do I unsubscribe from this list.
- Original Message -
From: Domien Bakker
To: [EMAIL PROTECTED]
Sent: Tuesday, November 20, 2001 6:30 AM
Subject: How to create a browser popup window
Hello all,
Can anybody give me the golden tip of creating a popup browser window
from my mod_perl handler? I want to fill in this popup window with results
generated within my handler.
Is there a module available from CPAN which can handle this?
Thanks in advance!
Met vriendelijke groet / With kind regards,
Domien Bakker
Application Developer
Application development
Operations and Engineering
ZeelandNet BV
Postbus 35
4493 ZG Kamperland
The Netherlands
tel. +31 (0)113 377733
fax +31 (0)113 377784
[EMAIL PROTECTED]
http://ww.zeelandnet.nl/
[OT] Re: How to create a browser popup window
On Tue, 20 Nov 2001, Rob Bloodgood wrote:
You must include code to deal with the fact that you may have already
opened a popup window. Something like this:
That is simply not true. window.open() with a named window ('popupwin', in
your example) ALWAYS reuses that window, on every browser I've ever been
able to test.
I didn't say duplicate windows was the problem. The problems are:
1) If the window exists it may have lost focus.
2) If the window exists you cannot resize it (eg for displaying full-size
images from thumbnails, etc.)
A corrected version of your sample script follows. It's much simpler now...
So simple it only does half of what it did :)
/THREAD ?
- nick
[OT] [But fun] Cookies and Microsoft
Speaking of the risks of using cookies for auth* stuff: http://dailynews.yahoo.com/h/cn/2009/tc/microsoft_apologizes_in_security_flap_1.html ~~~ Nick Tonkin
[OT] Re: CVS
I assume you are not expecting much to change in the database, and that you are therefore mostly doing selects, so why not continue to use MySQL? If you do, you can use MySQL's Update Log to take snapshots of the database whenever you want (and store them somewhere with date-appropriate names) and use them for versioning. Rolling back to an earlier version of your data is as simple as creating a new DB from your table defs, then mysqlbinlog log-file | mysql new-db See http://www.mysql.com/doc/B/i/Binary_log.html for more info. ~~~ Nick Tonkin On Thu, 15 Nov 2001, Jonathan M. Hollin wrote: Hi people, I am currently developing a content management system under mod_perl, with data stored in an RDBMS (MySQL at present, but Oracle on the production server). I would like to add version control to published documents (read pages) and wondered if anyone has any experience of this who would be willing to offer me some advice. I have a CVS server and am curious as to whether there is some way this can used (bearing in mind that I want to manage DB data, not files). I would like to be able to rollback to any previous version (if possible), and would also like to document the different versions themselves. I'm thinking that I could maybe commit the database files to CVS and then use a module to communicate with the CVS server (Apache-CVS, VCP, VCS-CVS, etc). Is this possible? Has anyone ever tried anything like this? I have searched CPAN and used Google to search the web and Usenet but have so far drawn a blank. I suspect that I will not be able to use CVS in this manner and that therefore I am going to have to roll my own. If this does turn out to be case - can anyone lend me any guidance as to how I work out what's changed in a record (between versions)? Then I can just store the changes in a DB as required. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: [challenge] new mod_perl site
On Thu, 15 Nov 2001, Stas Bekman wrote: Antoine Quint wrote: If you[1] don't like the way the site is now, don't bitch about it but change it completing the challenge. Well, I'd be up to having a crack at it... Would you be ok publishing the site with AxKit? Coding websites with it is so easy! Antoine, reread my original post. We are talking about suggesting a *design*, not how the site should be published ;) Well, he offered to design it, using the tools he knows how to use best. Since you are asking for people to give of their time and skills, perhaps you should be less imperious about _how_ you want it done. Perhaps you should be less imperious in general. Your challenge came off to me as imperious enough that I wasn't interested in offering to help, anyways. For God's sake, you made it seem like not only had all the decisions been made already (by you), but that if I didn't use the right subject line format for my contributions, I might as well not bother! Remember that while you have been lucky enough to get a nice paycheck for jam_ph-ing, the folks whose expertise you are trying to solicit will be volunteering their time and work. Be nice! Lately your postings here seem to be preponderantly of a critical tone, more concerned with taking people to task for not using [OT] in their subject line, or whatever, than with providing assistance and support to those who are seeking it, as you used to do so well. No one doubts your commitment to mod_perl, or your hard -- and unpaid -- work on the guide and many other things. But if you want to be a leader who inspires people to collaborate and work as a team under your direction, you'd do well to work on bringing your people skills up to par with your technical skills, IMHO. Have a nice day :) -nick
[OT] Nimda etc (was Re: New mod_perl hacker wannabe . . .)
Er, you might look at http://www.tonkinresolutions.com/MSIISProbes.pm.html ... Always a good idea to search the mod_perl list archives, as well as put out ideas in the present tense :) Nick ~~~ Nick Tonkin On Mon, 29 Oct 2001, Louis LeBlanc wrote: On 10/28/01 08:29 PM, Jeremy Rusnak sat at the `puter and typed: Just today, I finished a new module - my first from scratch - for handling 404 errors. I know Apache::404 isn't a real imaginative name, but it works. I took a look at this, it's a good idea for smaller sites. I would suggest that you figure out a way to put a rate limit on the number of E-mails that are sent warning the admin, though. On my site we receive over a million page views a day...When something gets broken I don't want to have 10,000 E-mails in my inbox. In addition, there are many black hats out there who might be tempted to use this an exploit. I once had a script that told the user Error blah blah...An E-mail has been sent to our support staff to notify them of the problem. Of course some people decided to call the script thousands of times and fill up the hard drive on our mail server. Of course, not all sites are going to have issues like this...But I think if you're going to be releasing modules it might be a good idea to include some notes for sites that MIGHT. Very good point. The CodeRed and Nimda modules have a cache mechanism (File::Cache, IIRC) that prevents repeat reports within a 24 hour period. Definitely a good idea. This would also help with the likes of the Nimda and CodeRed hits, so you would only get one per day of any of the unique URIs generating reports. Now I DO see the value of opening discussion *prior* to just throwing a module out! :) Look for V1.01 in the next week :) Thanks! Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Second Law of Final Exams: In your toughest final -- for the first time all year -- the most distractingly attractive student in the class will sit next to you.
Re: Mod_perl component based architecture
I do almost nothing but the kind of work you are describing, including a comprehesive student record management system for a large California College. I find that providing a custom interface to data is a lot more like static content than dynamic when it comes to design. My apps tend to look more like M$ Access than slashdot.org So, over time, I've built a set of tools that do exactly what I need. It's an extensible API, of course, so I can add new functionality simply, but it does just what I need. The reason I've never adopted Mason or OpenInteract or one of these [amazing] products is that because of their scope they do far more than I ever need them to. For the same amount of time and learning curve I would spend on becoming a Mason mason I can tweak my own API to be 100% to my liking. All the content-generation code I use is my own. Many people sniff at this and chuckle at another hacker going through the rite of passage of making his own templating system. But the toolkit I use has been built over four or five years now, so if I'm stuck in a rite, well, so be it. Works for me, rather well. I use a light layer of custom stuff built on top of the hardcore public APIs for non-content-generation stuff, i.e. Apache::Session- and DBI-based auth and data-access libraries. I have built an integrated access/auth/authz layer that gives each user a hash of their own permissions that follows them around; I use this to govern the output of the content-generation as to read-write, as you suggested, and logging is built into the write()s everywhere. I've been thinking of packaging up the auth/authz stuff ... anybody care to take a look at it? I guess in general I favor independent component APIs upon which you can build, a la Apache::Session, rather than the monster Application Servers ... it seems that you get the same effect but with more control. Of course, I've had the luxury of afew years' experience; someone starting out may prefer a canned solution ... - nick ~~~ Nick Tonkin On Tue, 16 Oct 2001, Bill Moseley wrote: I've been looking at OpenInteract, too. I've got a project where about 100 people need to edit records in a database via a web-based interface. And I'd like history tracking of changes (something like CVS provides, where it's easy to see diffs and to back out changes). And I need access control for the 100 people, along with tracking per user of how many changes they make, email notification of changes, administrative and super-user type of user levels, and bla, bla bla, and so on. Normal stuff. I'm just bored with html forms. Seems like I do this kind of project too often -- read a record, post, validate, update... Even with good templating and code reuse between projects I still feel like I spend a lot of time re-inventing the (my) wheel. Will an application framework bring me bliss? I'm sure this is common type of project for many people. What solutions have you found to make this easy and portable from project to project? Bill Moseley mailto:[EMAIL PROTECTED]
Re: MSIISProbes.pm v1.03
On Fri, 28 Sep 2001, Ask Bjoern Hansen wrote: On Thu, 20 Sep 2001, Mike Schienle wrote: thanks to patches from Brice D. Ruth and others, a new version of MSIISProbes.pm is available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz Hi all - Can anyone provide a couple hints on getting this going with Tenon's iTools on MacOS X? For Reuven's CodeRed, it was just a matter of putting CodeRed.pm in /Library/Perl and adding the following code to the iTools.conf file (equivalent to httpd.conf). [...] Any suggestions are greatly appreciated. check the code and your system configuration for the location of sendmail (or whatever the module uses to send mail). MSIISProbes.pm use Mail::Sendmail to send mail ... Cache::FileCache defaults to using /tmp for the location of its cache; does the system have /tmp (not sure what Cache::FileCache does if there's no /tmp, hafta look at the code). - Nick
[Announce] MSIISProbes.pm v1.03
Hello, thanks to patches from Brice D. Ruth and others, a new version of MSIISProbes.pm is available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz Changes: v1.03 Added code to get e-mail for the SOA of the host (Brice D. Ruth) Cut the DNS Resolver's timeout to 20 seconds v1.02 Moved the URL for info for each worm into PerlSetVar in httpd.conf comments/flames welcome --nick ~~~ Nick Tonkin
[OT] 408 http responses?
Hi all, sorry to bother, but has anyone else noticed a bunch of 408
(client timed out) requests beginning last evening?
Some but not all of these have also been trying the Nimda exploit. Perhaps
Nimda (or another Micro$oft product) is screwing up the clients?
nick@world /usr/local/apachessl/binperl -e
'open(L,/home/nick/logs/httpd_log); while(L){
chomp;my $r=m/408/?4:m/cmd|root|c\+di/?w:;
if($r){$_=~s/(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*/$1/;$c{$r}{$_}++;}}
foreach(sort{ $c{4}{$a}=$c{4}{$b} } keys %{ $c{4} }){
print$_\t\t[$c{4}{$_}]\t[$c{w}{$_}]\n;}'
207.249.143.170 [1] []
207.160.174.25 [1] []
62.149.161.207 [1] []
62.116.29.17[1] []
207.113.14.149 [1] []
209.129.49.65 [1] []
207.168.157.118 [1] []
207.202.38.140 [1] []
61.134.13.47[1] []
207.113.21.89 [1] []
24.67.119.127 [1] []
209.89.119.5[1] []
199.201.128.19 [1] [2]
207.113.25.50 [1] []
207.42.186.90 [1] []
207.113.25.249 [2] []
207.40.42.66[3] []
207.153.76.249 [4] []
207.241.153.3 [5] []
207.12.40.51[6] [16]
207.183.55.149 [6] []
207.217.138.18 [6] []
207.215.53.116 [7] []
207.152.93.12 [8] []
207.152.93.17 [8] []
207.77.187.76 [8] []
207.71.8.190[8] [384]
207.32.123.115 [9] []
207.252.220.55 [12][]
207.228.113.164 [12][]
207.242.45.234 [12][]
207.71.105.133 [13][112]
207.30.192.101 [14][]
207.248.190.158 [15][]
207.105.76.201 [15][]
207.215.126.141 [15][]
207.232.253.221 [16][]
207.245.74.7[16][]
206.221.254.59 [16][]
207.97.117.43 [16][]
207.208.128.185 [16][]
207.203.42.126 [16][]
207.190.221.23 [16][]
207.227.70.194 [16][]
207.127.178.25 [16][]
207.178.85.42 [16][]
207.153.199.78 [16][]
207.153.229.122 [16][]
207.236.169.100 [16][]
207.88.22.128 [16][]
207.252.1.68[16][]
207.170.35.143 [16][]
207.212.64.137 [16][]
207.76.239.206 [16][]
207.196.218.5 [16][]
207.137.76.119 [17][]
207.71.228.1[91][274]
~~~
Nick Tonkin
Re: [Announce] MSIISProbes.pm v1.03
Hi Jan, I'm afraid that might just gum up the bandwidth even more than these idiots (and our flame mail to them :) ... thanks for the support, though! ~~~ Nick Tonkin On Thu, 20 Sep 2001, Jan Jungnickel wrote: Hallo, thanks to patches from Brice D. Ruth and others, a new version of MSIISProbes.pm is available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz Changes: v1.03Added code to get e-mail for the SOA of the host (Brice D. Ruth) Cut the DNS Resolver's timeout to 20 seconds v1.02Moved the URL for info for each worm into PerlSetVar in httpd.conf If you like, you you add code to report infected Hosts to our Nimda-Database? You can find further informations on http://worm.jungnickel.com -- Greetings, Jan Jungnickel
[ANNOUNCE:] MSIISProbes v1.04 -- Stats!
Hi, a new version of MSIISProbes.pm is available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz This version provides support for statistics on each of the worms bugging you, thanks to Paul DuBois for the suggestion. From the docs: BStatistics You may wish to see the statistics for the various worms you are catching with MSIISProbes.pm. The module supports this through setting the value of the query string argument 'stats' to one of the worm names you defined in httpd.conf, for example like this: http://my.server.com/cmd.exe?stats=CodeRed or http://my.server.com/foo.bar?/c+dirstats=Nimda Just make sure to attache the query string to a URL that will be caught by your configuration of the module! Enjoy, -- nick ~~~ Nick Tonkin
NIMDA worm; MSIISProbes.pm
Hello, Now that Micro$oft has finally put out some information about their latest trick I have posted a new version of MSIISProbes.pm. Version 1.02 changes include putting the URL to a page containing info about each worm into a PerlSetVar ... this means that once you have configured MSIISProbes.pm with your e-mail and cacheing preferences, you can add traps for new worms as Micro$oft releases them, er, discovers them. Available at http://www.tonkinresolutions.com/MSIISProbes.pm.tar.gz More info at http://www.tonkinresolutions.com/MSIISProbes.pm.html Comments/flames welcome. - nick ~~~ Nick Tonkin
RE: [OT] New Micro$oft vulnerability?
On Wed, 19 Sep 2001, Lyle Brooks wrote:
One motivation I have is for these virus attacks, I'd like to send out
a 403 - Forbidden right at the beginning (say, when someone asks for
default.ida) and then I'd like to have the option of not logging it to
keep it from growing my logs and distorting my log reports.
Is there anyway to selectively tell a request not to even log this?
Disable the log handler for the current request, maybe?
Try something like this in your httpd.conf:
SetEnvIf Request_URI /default.ida dontlog
LogFormat %h %V %u %{%D %T}t %s %m %U%q common
CustomLog /home/nick/logs/httpd_log common env=!dontlog
- nick
Re: NIMDA worm; MSIISProbes.pm
On Wed, 19 Sep 2001, Bruce Albrecht wrote:
I was looking at your Apache::MSIISProbes module, and I didn't
understand the part about the nimda rewrite rules, mostly because I
haven't used the rewrite rules. Do the following rules
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.dir
RewriteRule .* /nimda? [R,L]
mean unless I've already rewritten the rule, if the query string matches
c.dir (i.e., will match c+dir found in most of the requests), rewrite
the request as /nimda?
right.
From my observation, nimbda also tries c+tftp
and tries to get /scripts/Admin.dll, /c/Admin.dll, /d/Admin.dll and
/MSADC/Admin.dll. Could I change the rewrite rules to
RewriteCond %{REQUEST_URI} !nimda
RewriteCond %{QUERY_STRING} /c.(tftp|dir)
RewriteRule .* /nimda? [R,L]
to catch either request, and then do
RewriteCond %{REQUEST_URI} /(scripts|MSADC|c|d)/Admin.dll
RewriteRule .* /nimda? [R,L]
to catch the others?
Well, the rules you put forward seem fine, but I'm not sure you'll catch
everything ...
BTW the '?' on the end is to remove the query string ... if you leave it
off mod_rewrite puts the original one back.
- nick
