RE: Invoke PHP scripts?
How about using php in cgi mode and using `php scriptname` from within perl to capture the output? Not the best performance-wise, but it would do what you want, I think. Jim -- James Helm - Solaris System Administrator [EMAIL PROTECTED] WNS National Operations - Core Services [EMAIL PROTECTED] ATT Wireless Services Inc. (425) 288-4395 (Desk) 3555 Monte Villa Pkwy, Bothell, WA 98021 (206) 618-0438 (Cell) -Original Message- From: Ryan Thompson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 8:48 PM To: [EMAIL PROTECTED] Subject: Invoke PHP scripts? Hi there, Apologies if this has been asked 2^32 times, but I couldn't seem to find anything in the archives or on the web which would solve my problem. I'm developing a large-ish web site in which I would like to use a combination of mod_perl (90%) and PHP (10%). I have run into a roadblock trying to include the output of a PHP script from a mod_perl script. This would do fine: my $r = Apache-request(); return $r-lookup_uri($url)-run; But (and I am familiar with why this happens) run() dumps the results to STDOUT, so the final HTML does not come through in the correct order. I tried to use Apache::SSI in this manner: my $r = Apache-request(); my $ssi = Apache::SSI-new($contents, $r); return $ssi-get_output(); (Where $contents is the raw PHP source), but, possibly because of some Content-type mixup, the output is returned as expected (i.e., not dumped to stdout), but the PHP source is not interpreted. So, in short, I need another way to invoke a PHP script from my mod_perl application... exactly what !--#include virtual=... -- would do. Help..? :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-664-3630 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Persistent Net::Telnet Objects
Perhaps you can put a System V message Queue in front of both Telnet
connections, this way producers can place their messages in the queue
asynchronously , and the backend (consumer) can pick them up in a FIFO.
Also, try using Net::SSH::Perl. The Net::Telnet does not give your things
like
STDOUT, vs STDERR, vs Exit code. Net::Telnet puts everything in one
channel.
The Security is yet another issue, specially when the session could
be open
and idle for exessive amount of time. Your session can be hijacked
easily.
"French, Shawn" wrote:
Vitals:
Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a
on
Windows 2000 with PHP 4.21
I am working on a project that requires me to have two telnet objects
per
user session opened, and accessible throughout the user's session.
I have
looked at Apache::Session and many other solutions but my problem is
that to
keep a Net::Telnet object, I need to keep open sockets and filehandles,
so I
cannot serialize the object and store it in a database or file.
Currently I have similar code working flawlessly:
###
# "startup.pl" - called when apache starts (ie. PerlRequire
"d:/Apache/conf/startup.pl")
##
use MySite::Session;
###
# "Session.pm"
##
@EXPORT = qw( %sessionHash );
our %sessionHash;
###
# "init_session.pl" - called IN MOD_PERL when a new session is requested
##
use MySite::Session;
$sessionHash{$session_id . "_telnetObj"} = Net::Telnet->new();
###
# "dostuff.pl" - called IN MOD_PERL many time throughout the session
##
use MySite::Session;
my telnetObj = $sessionHash{$session_id . "_telnetObj"};
bless (\$telnetObj, "Net::Telnet");
Although this is working right now, I don't know enough [ anything?
:) ]
about Apache or mod_perl to be sure that this will work in the future.
What
I am really concerned about is that the telnetObj will only be accessible
from scripts run by the same child process as that which created and
saved
it.
Is there a better way to do this?
Thanks,
Shawn French
--
-
Medi Montaseri [EMAIL PROTECTED]
Unix Distributed Systems Engineer HTTP://www.CyberShell.com
CyberShell Engineering
-
RE: Invoke PHP scripts?
On Wed, 29 May 2002, Jim Helm wrote: How about using php in cgi mode and using `php scriptname` from within perl to capture the output? Not the best performance-wise, but it would do what you want, I think. will the cgi environment be preserved? --- Gabriel Millerd | When I grow up I want a job where I run around in Plumber |circles chasing my tail like an idiot ten hours a day. |-- Monster.com
RE: Persistent Net::Telnet Objects
I just found this: http://www.devshed.com/Talk/Books/ProApache/page2.html On Windows platforms, Apache does not fork; consequently, the directives for controlling the number of processes or their lifetime have no effect. Instead, Apache runs as a multi-threaded process Recall that I am using: Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4 OpenSSL/0.9.6a on Windows 2000 with PHP 4.21 Would this be why my scripts are working? Does this mean that as long as I stay with windows I will be alright? I realize (as Medi Montaseri pointed out) that my scripts might not be too secure (ie. hijacking a telnet session) however I am only concerned about getting this working, and making sure it will remain working, as it will be run behind a firewall in a corporate intranet. For now I will continue coding with my current architecture hoping that the above mentioned information is correct. Thanks for all the help! Shawn
Getting AuthCookie to work on W2K
Hello All,
I am trying to setup the Apache-AuthCookie module and have run into a
problem. Every time
I try to login it just returns my back to the login screen. I can't get past
the login screen!!
(I have tried with Netscape and IE). Next I wrote a perl script to check
things out. (same thing!!)
according to the apache log file it seems that the server is not receiving
the cookie but according
to the LWP debug information it is sending it out!!
Does anyone have any idea what is wrong? What have I missed?
Thanks
Ron
login.pl script=
#!/usr/bin/perl -w
use HTTP::Request::Common;
use HTML::Form;
use LWP::UserAgent;
use LWP::Debug qw(+);
BEGIN {
local $^W = 0;
*LWP::UserAgent::redirect_ok = sub {1}
}
use HTTP::Cookies;
use strict;
my $ua= LWP::UserAgent-new;
$ua-cookie_jar(
HTTP::Cookies-new(
autosave = 1 )
);
my $request = $ua-request( POST 'http://cypci748/uganswer/index.html' );
#print $request-as_string;
my $form = HTML::Form-parse( $request-content, $request-base());
$form-value( 'credential_0', programmer );
$form-value( 'credential_1', Hero );
my $response = $ua-request( $form-click('submit') );
print $response-as_string;
=output from login.pl (lwp debug
information)=
F:\scriptslogin.pl
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/uganswer/index.html
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 763 bytes
LWP::Protocol::collect: read 692 bytes
LWP::UserAgent::request: Simple response: OK
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/LOGIN
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 265 bytes
HTTP::Cookies::extract_cookies: Set cookie Apache::UGA::AuthCookieHandler_Wh
er = programmer:Hero
LWP::UserAgent::request: Simple response: Found
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/uganswer/index.html
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 763 bytes
LWP::Protocol::collect: read 692 bytes
LWP::UserAgent::request: Simple response: OK
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Date: Thu, 30 May 2002 13:51:59 GMT
Pragma: no-cache
Server: Apache/1.3.19 (Win32) AxKit/1.51 mod_perl/1.26
Content-Length: 1455
Content-Type: text/html
Expires: Thu, 30 May 2002 13:51:59 GMT
Client-Date: Thu, 30 May 2002 13:51:59 GMT
Client-Response-Num: 1
[ the login form was here]
Apache error_log
file===
[Thu May 30 06:51:59 2002] [error] auth_type Apache::UGA::AuthCookieHandler
[Thu May 30 06:51:59 2002] [error] auth_name WhatEver
[Thu May 30 06:51:59 2002] [error] ses_key_cookie
[Thu May 30 06:51:59 2002] [error] uri /uganswer/index.html
[Thu May 30 06:51:59 2002] [error] Converting POST - GET
[Thu May 30 06:51:59 2002] [error] credential_0 programmer
[Thu May 30 06:51:59 2002] [error] credential_1 Hero
[Thu May 30 06:51:59 2002] [error] ses_key programmer:Hero
[Thu May 30 06:51:59 2002] [error] auth_type Apache::UGA::AuthCookieHandler
[Thu May 30 06:51:59 2002] [error] auth_name WhatEver
[Thu May 30 06:51:59 2002] [error] ses_key_cookie
[Thu May 30 06:51:59 2002] [error] uri /uganswer/index.html
Apache http.conf file for
AuthCookie
Location /perl/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Location
PerlModule Apache::AuthCookie
PerlModule Apache::UGA::AuthCookieHandler
PerlSetVar WhatEverPath f:/Apache/cgi-bin/
PerlSetVar WhatEverLoginScript /perl/login.pl
PerlSetVar AuthCookieDebug 3
Location /uganswer/
AuthType Apache::UGA::AuthCookieHandler
AuthName WhatEver
PerlAuthenHandler Apache::UGA::AuthCookieHandler-authenticate
PerlAuthzHandler Apache::UGA::AuthCookieHandler-authorize
Require user programmer
/Location
Location /LOGIN
AuthType Apache::UGA::AuthCookieHandler
AuthName WhatEver
SetHandler perl-script
PerlHandler Apache::UGA::AuthCookieHandler-login
/Location
RE: Persistent Net::Telnet Objects
It it possible that KeepAlives are what's making this work? If the user is active enough, in theory, they would always be connected to the same httpd process... Jim -- James Helm - Solaris System Administrator [EMAIL PROTECTED] WNS National Operations - Core Services [EMAIL PROTECTED] ATT Wireless Services Inc. (425) 288-4395 (Desk) 3555 Monte Villa Pkwy, Bothell, WA 98021 (206) 618-0438 (Cell) -Original Message- From: French, Shawn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 1:50 PM To: 'Perrin Harkins' Cc: [EMAIL PROTECTED] Subject: RE: Persistent Net::Telnet Objects Perrin wrote: I can't see how it could be working now That makes two of us! You're probably opening new telnet connections from each apache process. I know that I am not since they are continuing to log to the same dump file, and my code (as stated in previous message) simply goes to the hash and takes the object. That won't work, since you can't control which process will handle requests from the client. OK, is there a way to make sure that there is just one process? This site is not for milions of users, only 10 - 20. I'm sure that others have had to keep persistent sockets and/or filehandles on their server, and I really don't see how my problem is any different... Please, can anybody help me? Shawn
Re: Persistant references [was] Persistent Net::Telnet Objects
I have thought about this, and it's something I'm willing to do if I have
to. I would much rather be able to store an actual code ref and avoid the
overhead of many string-form eval's. Is there no way to do this?
-- Ryan
- Original Message -
From: Garth Winter Webb [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 29, 2002 11:16 PM
Subject: Re: Persistant references [was] Persistent Net::Telnet Objects
You could just pass around a string rather than a subref:
my $handler = 'sub { my $arg = @_; do_something(); }';
vs
my $handler = sub { my $arg = @_; do_something(); };
When you want to call it later on you do it like:
eval($handler)-('foo');
vs
$handler-('foo');
Garth
On Wed, 2002-05-29 at 22:17, Ryan Parr wrote:
I never do give enough info on the first e-mail. Thank you for bearing
with
me...
What I mean is, if a request comes in for a certain form I would like to
be
able to do something like this:
my $form = load_form($r);
$c{$session_id}-{handler} = $form-{handler}; # -- this being a code
ref...
$r-send_http_header;
print $form;
Then when the user completes the form and resubmits:
my $handler = $c{$session_id}-{handler};
$r-send_http_header;
print $handler-($r);
This is definately simplified, but the idea is there. I would like to be
able to store anything that can be referenced and have it be available
to
all processes. I would like to be able to dynamically create anonymous
subroutine handlers based on input and have them be active until the
form is
submitted, at which time they are used to process the form then
discarded.
Is this something that can be accomplished? The global hash using Perl
aliasing
(http://thingy.kcilink.com/modperlguide/perl/Using_the_Perl_Aliasing_Feature
_.html) works beautifully, until of course the form is submitted to
another
httpd process, and I'm hoping to not have to limit myself to just one
child.
Obviously this can't be serialized, but there has to be *some* way to do
this...
-- Ryan
- Original Message -
From: Ryan Parr [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 29, 2002 9:16 PM
Subject: Persistant references [was] Persistent Net::Telnet Objects
Along these same lines I'm seeking a way to store a code reference
into a
global hash that is shared among all processes. For example:
my $session_id = get_session_from_cookie($r);
my $handler = $c{$session_id}-{handler};
$r-send_http_header;
print $handler-($r);
return OK;
Has anyone performed this kind of magical tidbit before? Is there some
main
process repository that I can access?
-- Ryan
- Original Message -
From: Rob Mueller (fastmail) [EMAIL PROTECTED]
To: French, Shawn [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, May 29, 2002 5:35 PM
Subject: Re: Persistent Net::Telnet Objects
Our project needed persistent socket connections open as well. There
is
supposed to be a standard mechanism to pass file descriptors between
unix
processes, though it's bugginess level depends on your OS. There is
a
perl
module for this called Socket::PassAccessRights. So what you can do
is
create a daemon process that just hangs round holding socket
connections
open, like a socket cache basically, and passing them back and forth
between
Apache processes based on some session ID or user ID or the like.
Your daemon ends up looking something like this (with lots more
error
checking of course)
my %sockmap;
while (1) {
my $clientsock = $listen-accept();
chomp(my $sessionid = $clientsock);
my $cachesock = ($sockmap{$sessionid} ||= opennewsock());
Socket::PassAccessRights::sendfd(fileno($clientsock),
fileno($cachesock));
$clientsock-close();
}
And in your mod_perl code you do something like:
my $serversock = IO::Socket::INET-new(Server = 'localhost', Port
=
SOCKETPOOLPORT);
print $serversock $sessionid, \n;
my $Fd = Socket::PassAccessRights::recvfd(fileno($serversock));
open(my $realsocket, =$Fd);
fcntl($realsocket, F_SETFD, 0);
my $ofh = select($realsocket); $| = 1; select ($ofh);
If you do some experimenting, you'll get something that works,
you'll
also
find lots of cases that don't.
Rob
- Original Message -
From: French, Shawn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 30, 2002 3:53 AM
Subject: Persistent Net::Telnet Objects
Vitals:
Apache/1.3.20 (Win32) mod_perl/1.25_01-dev mod_ssl/2.8.4
OpenSSL/0.9.6a
on
Windows 2000 with PHP 4.21
I am working on a project that requires me to have two telnet
objects
per
user session opened, and accessible throughout the user's session.
I
have
looked at Apache::Session and many other solutions
Re: AuthzHandler, index.html not being accessed
A note: since cookie is involved, why not to implement all the access/authentication/authurization functions at the access control phase using cookie ? Peter I've got an interesting problem, related to my development of some Authen/Authz handlers. I have a directory on which I've installed an Access, Authen, and Authz handler: - the Access handler makes sure a cookie exists, and redirects the user to a login page if it doens't. If the cookie does exist, populate $r-connection-user. This works. - Authen handler currently returns OK - it will be used to validate the user as stored in the cookie If I 'require valid-user' in the directory, my authz handler doesn't get invoked, which I expect. However, If I request the directory (ie. /test/) I get a directory listing instead of index.html. If I take out the require, thereby bypassing authen/authz, I get index.html. If I also put in custom 'requires', my authz handler is invoked, and the same thing happens. So, it seems that when OK is returned from an authz handler, the DirectoryIndex is not being read. I've been unsucessful in trying to find a solution. Ideas? -klm. BTW, I understand that what I'm doing does appear to be similar to Apache::AuthCookie, but I have a few different requirements that I need to incorporate
Re: AuthzHandler, index.html not being accessed
I should also mention this: Apache/1.3.23 (Unix) mod_perl/1.26 - Original Message - From: Ken Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 11:12 AM Subject: AuthzHandler, index.html not being accessed I've got an interesting problem, related to my development of some Authen/Authz handlers. I have a directory on which I've installed an Access, Authen, and Authz handler: - the Access handler makes sure a cookie exists, and redirects the user to a login page if it doens't. If the cookie does exist, populate $r-connection-user. This works. - Authen handler currently returns OK - it will be used to validate the user as stored in the cookie If I 'require valid-user' in the directory, my authz handler doesn't get invoked, which I expect. However, If I request the directory (ie. /test/) I get a directory listing instead of index.html. If I take out the require, thereby bypassing authen/authz, I get index.html. If I also put in custom 'requires', my authz handler is invoked, and the same thing happens. So, it seems that when OK is returned from an authz handler, the DirectoryIndex is not being read. I've been unsucessful in trying to find a solution. Ideas? -klm. BTW, I understand that what I'm doing does appear to be similar to Apache::AuthCookie, but I have a few different requirements that I need to incorporate
Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Subject pretty much says it all. What are the requisite 5.8 compile options, besudes ithreads, for proper functioning with either mod_perl branch? Or ones that should be avoided? Chip -- Chip Turner [EMAIL PROTECTED] Red Hat, Inc.
RE: separating C from V in MVC
Hi Ray --
I'm looking for some pointers on MVC in this context. Specifically, M
is easy ... use Perl objects, but how are others implementing the
Controllers and Views in order to keep them separate?
[...snip...]
What's the right way to do it? (None of this TMTOWTDO stuff now, I
want the RIGHT way :-) ... and do I have the concepts right?
You want to do it the RIGHT way?
Before diving off into an abstract conversation about design patters...
It has been my experience that applying a design pattern such as MVC is not
a panacea. It's more important to devise a system which works than one
which is academically correct. The most useful thing one can do with
their CS education is often to immediately forget everything they've learned
except the stuff which actually works at a practical level. My point: My
code isn't good because I apply some pattern to it. It may be good, and
it may resemble a pattern -- but those two things are largely coincidental.
:-)
That said, MVC has been a corner-stone of how my company develops web apps
in Perl. It has been our architecture for several years. The concepts are
pretty simple, and I think you already have most of the picture. In brief
--
Model: The business logic. Not related to the UI at all.
View: The user interface.
Controller: The glue between the View and the Model.
As you have already identified, the Model is simply a Perl module. The most
important thing to think of when writing a Model module is to make sure you
make it entirely separate from the user interface. It helps me to think of
the methods in the Model as potentially being called from a web application,
a cron script, or an email-based interface. The Model should not contain
anything specific about any of the interfaces through which it might be
accessed.
The View, in a web application, is really the HTML output. Generally, this
will be your templating system. Optimally, the View avoids *ALL*
application logic. At my company we use HTML::Template because it strongly
enforces the separation of View from Controller -- e.g., HTML from code. (I
realize that many of you prefer other HTML templating systems, but I still
contend that HTML::Template is the most effective system for truly
separating HTML from code. And it's damn fast, too.)
The Controller, as I've already described, connects the View to the Model.
Essentially, the Controller takes user input (e.g., HTTP request input, form
data, environment, etc.) and translates it into method calls on the
underlying Model. The Controller then takes output from the Model and
passes it to your View.
We implement our Controllers as CGI::Application modules. CGI::Application
completely encapsulates a single application into an object-oriented Perl
module which runs a particular application. CGI::Application runs perfectly
under mod_perl, and with a little savvy can be made to play nicely with just
about any architecture. Oh yes -- it also runs outside of mod_perl, outside
of Apache, and will even run on Windows should that be one of your
requirements.
As your message indicated, separating the View from Controller is a problem.
In fact, it is actually a problem related specifically to Server Page
architectures such as Mason, EmbPerl, Cold Fusion, ASP or JSP. All these
systems are server-page systems (SPS), and all suffer from problems in
separating the View from the Controller.
Ironically, SPS were invented in response to CGI scripts. CGI scripts
were largely criticized because they, too, combined the View and the
Controller. When you look at it like that it's hard to argue that SPS have
really improved the situation at all.
If you have to work with an SPS such as Mason but you still want to separate
your View from your Controller, you have to work twice as hard. SPSs
encourage the View and Controller to be in the same document. In fact, it's
virtually impossible to entirely separate them. One of the things which
irks me most about SPS code is when I see the re-invention of old-school,
CGI-style coding in the middle of a server-page. How do you know when your
SPS is working against you? When you see this in the middle of your
[Mason|EmbPerl|JSP|ASP|Cold Fusion] page:
if (defined($some_form_param)) {
# 50 lines of spaghetti code to run a search
} else {
# 30 lines of spaghetti code to display a form
}
That, my friends, is what happens when an SPS is used in lieu of a real
architecture. Separating your Controller and View is a great cure for this
ailment.
Warmest regards,
-Jesse-
Jesse Erlbaum, CTO
Vanguard Media
http://www.vm.com
212.242.5317 x115
[EMAIL PROTECTED]
DBI error_log Logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been researching the different modules for pushing your access log to a dbi storage vs. local file and have one question which I'm not sure any of them are able to do yet. Perhaps somebody has already thought of this and I'm just not seeing the answer (very likely). I need to log my error_log entries also, not just the access log. If there is one, especially if it's Apache::DBILogConfig (my favorite appearing so far) with that same customization, that would be excellent. Otherwise I'd like to know, because I'll probably have to make one *real* quick :) Also, if it has the ability to either trigger an event, or just log to file the inability to log via DBI, that would be nice. Jayce^ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE89q8CoTgdT9hhlCIRAjoEAJwKsO9LYavsWMQGwUsD11E1Gr9HiACgl1yR mvvJRsub4he4A4PaPoA8PEI= =E5ID -END PGP SIGNATURE-
Re: DBI error_log Logging
Jayce^ wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've been researching the different modules for pushing your access log to a dbi storage vs. local file and have one question which I'm not sure any of them are able to do yet. Perhaps somebody has already thought of this and I'm just not seeing the answer (very likely). I need to log my error_log entries also, not just the access log. this is _far_ trickier than you might suspect at first. for a detailed explanation, see Recipe 16.6 in the mod_perl Developer's Cookbook. the code we used to implement error log capturing is here: http://www.modperlcookbook.org/code/ch16/Cookbook-DivertErrorLog-0.01.tar.gz while sample (but working) code that uses the interface is here: http://www.modperlcookbook.org/code/ch16/Cookbook/ErrorsToIRC.pm paul, randy, and I were all able to get this module to work on three different platforms (including windows) but I'm still not sure how robust it is for production use. nevertheless, it should give you an idea as to why there aren't any modules on CPAN that do this :) --Geoff
IE login script woes
(I'm cc'ing the list in hopes that maybe this will help others when deailing with custom error documents that aren't working under IE - there have been a few people having problems with login pages and some of the Apache::Auth* modules, and maybe this will help. If it's old news to everyone, I apologize) Michael, I found something relating to IE (ain't MS grand!) and custom error pages not appearing under the right (wrong?) conditions... Basically, if friendly http error messages is turned on for IE 5.X+, your custom error page has to be over a certain size in order for IE to display the original and not it's own friendly version. The defaults for IE6.0 (don't have an older one to test with) are anywhere from 256 to 512 bytes, depending on the error code returned. I had a user who was having this problem on my site. Took me a while to figure it out too, since I always turn the pesky thing off on my systems. I eventually remembered there was a way to override them, and a quick search on MS Support site turned up the answer. Anyway, that alternate login script I sent to you needs a minor tweak - basically adding 512 spaces (as simple as ' 'x512) to both the refresh page and the actual login page, so as to prevent the intelligent code in IE from hiding the pages. It shouldn't be a problem for most login pages, but the refresh page I'm using to make http-https-http logins work didn't have anywhere near the 512 bytes needed. Hope that's useful to you somehow. Later, Jim
Confusion: Perl/mod_perl ????
Hi, I have been programming in Perl for about 3 weeks now, and I just started doing some Perl CGI. I have Apache 2 installed on my linux system, but and my perl scripts work fine, but I don't knwo whether or not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up untill recently that Apache has it's own version of Perl that it uses for CGI scripts (mod_perl) but I am now having doubts. Could someone please tell me exactly what the difference is between Perl and mod_perl, and how exactly mod_perl is used (.i.e. is it just for writing apache modules or is it just for CGI, or what) I'm big-time confuesd here. Thanks very much!!! Jeff.
Re: Confusion: Perl/mod_perl ????
On Thu, 30 May 2002, Jeff McLean wrote: Hi, I have been programming in Perl for about 3 weeks now, and I just started doing some Perl CGI. I have Apache 2 installed on my linux system, but and my perl scripts work fine, but I don't knwo whether or not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up untill recently that Apache has it's own version of Perl that it uses for CGI scripts (mod_perl) but I am now having doubts. Could someone please tell me exactly what the difference is between Perl and mod_perl, and how exactly mod_perl is used (.i.e. is it just for writing apache modules or is it just for CGI, or what) I'm big-time confuesd here. Thanks very much!!! Jeff. Hi Jeff - First go to the http://perl.apache.org/ site to get the full story. In short, think of mod_perl as a module that you start up with Apache that allows all of the perl scripts to run faster because the server doesn't have to launch a subprocess because mod_perl is in a sense Apache's version of perl. There are a lot of options/etc (this *is* perl we're talking about), so keep that in mind as you read through the documentation for what is applicable to your website. If you're using mod_perl, you can check your log when you start up Apache for something like this: [Fri May 24 14:50:24 2002] [notice] Apache/1.3.22 (Unix) mod_perl -- ~~ Doug Silver Network Manager Urchin Software Corp.http://www.urchin.com ~~
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Chip Turner wrote: Subject pretty much says it all. What are the requisite 5.8 compile options, besudes ithreads, for proper functioning with either mod_perl branch? Or ones that should be avoided? it may be different on your OS (read the INSTALL doc), but on linux 2.4 I compile with all the defaults (-des): ./Configure -des -Dprefix=/home/stas/perl/ithread \ -Dusethreads -Duseshrplib and I add: -Doptimize='-g' so I can debug problems (don't put it in for production use) -Duseshrplib builds a shared libperl Also you don't need -Dusethreads (which is a bit slower) if you don't plan on using perl threads and threaded Apache mpms (i.e. when you use prefork) __ 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: Confusion: Perl/mod_perl ????
Doug Silver wrote: On Thu, 30 May 2002, Jeff McLean wrote: I have been programming in Perl for about 3 weeks now, and I just started doing some Perl CGI. I have Apache 2 installed on my linux system, but and my perl scripts work fine, but I don't knwo whether or not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up untill recently that Apache has it's own version of Perl that it uses for CGI scripts (mod_perl) but I am now having doubts. Could someone please tell me exactly what the difference is between Perl and mod_perl, and how exactly mod_perl is used (.i.e. is it just for writing apache modules or is it just for CGI, or what) I'm big-time confuesd here. First go to the http://perl.apache.org/ site to get the full story. In short, think of mod_perl as a module that you start up with Apache that allows all of the perl scripts to run faster because the server doesn't have to launch a subprocess because mod_perl is in a sense Apache's version of perl. There are a lot of options/etc (this *is* perl we're talking about), so keep that in mind as you read through the documentation for what is applicable to your website. Actually the new site (which should be released realy soon now) has a nice and easy intro to mod_perl (thanks to Bill Moseley and others who helped): http://perl.apache.org/release/start/index.html So Jeff, you may want to start from this URL first. __ 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: DBI error_log Logging
Quoting Jayce^ [EMAIL PROTECTED]:
I've been researching the different modules for pushing your access log to a
dbi storage vs. local file and have one question which I'm not sure any of
them are able to do yet. Perhaps somebody has already thought of this and
I'm just not seeing the answer (very likely).
I need to log my error_log entries also, not just the access log.
For a non mod_perl way of dumping error_log into a DB just use the standard
Apache ErrorLog directive with a pipe:
ErrorLog | /usr/local/apache/bin/error_logger.pl
and in error_logger.pl just read from STDIN ( while () {#do something} ) and
do what you please with the log entries.
Cees
If there is one, especially if it's Apache::DBILogConfig (my favorite
appearing so far) with that same customization, that would be excellent.
Otherwise I'd like to know, because I'll probably have to make one *real*
quick :) Also, if it has the ability to either trigger an event, or just
log to file the inability to log via DBI, that would be nice.
Jayce^
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE89q8CoTgdT9hhlCIRAjoEAJwKsO9LYavsWMQGwUsD11E1Gr9HiACgl1yR
mvvJRsub4he4A4PaPoA8PEI=
=E5ID
-END PGP SIGNATURE-
--
Cees Hek
SiteSuite Corporation
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
./Configure -des -Dprefix=/home/stas/perl/ithread \ -Dusethreads -Duseshrplib Also worth using large file support if you habitually munge 2GB files. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
RFC: Apache::DefaultCharset
Here's a tiny XS mod_perl module to configure AddDefaultCharset stuff
from mod_perl. This is my first XS hack, thanks to mod_perl
developer's cookbook.
Any suggestions are welcome.
http://bulknews.net/lib/archives/Apache-DefaultCharset-0.01.tar.gz
=head1 NAME
Apache::DefaultCharset - AddDefaultCharset configuration from mod_perl
=head1 SYNOPSIS
use Apache::DefaultCharset;
my $charset = Apache::DefaultCharset-new($r);
print default_charset_name is , $charset-name;
# or print default charset is $charset; will do (overload)
$charset-name('euc-jp'); # modify default_charset_name in run-time
=head1 DESCRIPTION
Apache::DefaultCharset is an XS wrapper for Apache Core's
CAddDefaultCharset configuration.
=head1 EXAMPLES
=head2 Unicode Handling
Suppose you develop multi-language web application, and transparently
decode native encodings into Unicode string inside Perl (5.8 or over
would be better). First you should add
AddDefaultCharset euc-jp
in your Chttpd.conf, then leave off Csend_http_header arguments
just to text/html. Then you can get the current configuration with
this module when you use CEncode or CText::Iconv to decode the HTTP
request query into Unicode.
=head2 Modification of DefaultCharset
Suppose you want to add utf-8 for XML files, and Shift_JIS for HTML
files as HTTP charset attribute by default (By default means that if
you set Ccontent_type explicitly in content-generation phase, that
will be prior to the defalut). This module enables you to write
CPerlFixupHandler to configure Cadd_default_charset_name in
run-time.
=head1 AUTHOR
Tatsuhiko Miyagawa Elt[EMAIL PROTECTED]gt
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
=head1 SEE ALSO
LApache::GuessCharset
mod_perl cookbook at http://www.modperlcookbook.com/
=cut
Re: RFC: Apache::DefaultCharset
At Fri, 31 May 2002 13:58:52 +0900, Tatsuhiko Miyagawa wrote: =head1 SEE ALSO LApache::GuessCharset mod_perl cookbook at http://www.modperlcookbook.com/ s/com/org/ -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
