Re: webmail for mod_perl?
On Thu, Feb 28, 2002 at 03:59:05PM -0800, Wim Kerkhoff wrote: > will trillich wrote: > > > > is there a sane implementation of webmail-style mod_perl > > modules for apache? > > Are you needing any specific functionality? > > sparkle (a rewrite of acmemail) works as a mod_perl handler, under > Apache::Registry, and of course as a normal CGI. Works with various IMAP > servers via Mail::Cclient. Uses Template Toolkit for > themes/templates/skins. > > It's quite peppy once you add all the modules into startup.pl. this looks like what we need. cool. thanks! and now for some evidence that i saw the documentation... -- "We will fight them on the beaches, we will fight them on the sons of beaches" -- Miguel Churchill, Winston's bastard Mexican brother. --lifted from http://www.astray.com/acmemail/stable/documentation.xml [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
webmail for mod_perl?
is there a sane implementation of webmail-style mod_perl modules for apache? we're looking to offer email access online through apache/mod_perl similar to what folks get at yahoo/egroups -- and we're hoping to find some mod_perl code that'll hook into pop/imap email servers. (and we're hoping to avoid loading php into ram.) i saw a thread in the archives (begun on Wed, 12 Dec 2001 by Medi Montaseri) but most of the suggestions seemed to point to php. we're hoping to stick with mod_perl. :) rtfm welcome if you specify which fm to r. :) thanks... --thanks! -- Legalize Liberty. [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Form Reading
On Tue, Jan 08, 2002 at 11:01:43AM -0500, Robert Landrum wrote: > -- > When I used a Mac, they laughed because I had no command prompt. When > I used Linux, they laughed because I had no GUI. aha. the mac now has a cli (osX) and linux has had a gui for quite some time (x)... :) -- The only virus scanners I am aware of that run under linux are designed to scan for Windows viruses in traffic that the linux server is handling. -- Dave Sherohman, on debian-user [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
keeping client images private
y'all seem to have some clever brains out here, so i'm wondering if some of you can offer suggestions-- what's a good clean way to keep images private per customer? i'm using mod_perl and HTML::Mason with session cookies, but coming up with a paradigm for storing and revealing images privately has got me a bit flummoxed. mr. smith has pix which he can see when he logs in to the website, and mr. brown has pix of his own, but neither can see the other's images. each customer can have two levels of imagery (main images/subsidiary images). i could have a handler intercept image requests and deny access if session->user isn't valid ... should i just make an apache alias to handle images as if they're from a certain subdir? and then use mod_perl to redirect the requests to the actual images internally? or actually store the images in actual subdirs of the documentroot? is there a better/faster/cheaper way? i'm sure there's more than one way to do this -- and before i take the likely-to-be-most-circuituitous route, i thought i'd cull advice from the clever minds on this list... -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: mod_perl proxy to mod_ssl or vice-versa?
On Mon, Sep 10, 2001 at 04:02:04PM -0400, Perrin Harkins wrote: > > i've seen discussion at perl.apache.org/guide about having a > > hefty mod_perl server with a lightweight server proxying > > the heavy-lifting requests to the mod_perl server (same machine, > > different machine). > > > > can this be done with mod_ssl and mod_perl? > > Yes, lots of people do that. You need the front-end to have mod_proxy and > mod_ssl. that makes sense. > > internet firewall mod_ssl backend mod_perl > > > [1.2.3.4] > [192.168.7.10] > > :443 ssl verify ---> apache:80 > > :80 portforward --> apache:80 > > > > i'm thinking of using port forwarding on 1.2.3.4 to send :80 http > > requests directly to the mod_perl server, and have :443 https > > requests get verified thru the mod_ssl server which then also get > > sent to the mod_perl server at 192.168.7.10 (HTML::Mason needed > > to do the work). > > I suggest you have both go through the front-end server. There are multiple > reasons to do this, which are outlined in the guide. are you referring to the guide's 'scenarios' section where two servers are cached via squid? it's over my head... -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
mod_perl proxy to mod_ssl or vice-versa?
i've seen discussion at perl.apache.org/guide about having a hefty mod_perl server with a lightweight server proxying the heavy-lifting requests to the mod_perl server (same machine, different machine). can this be done with mod_ssl and mod_perl? internet firewall mod_ssl backend mod_perl > [1.2.3.4] > [192.168.7.10] :443 ssl verify ---> apache:80 :80 portforward --> apache:80 i'm thinking of using port forwarding on 1.2.3.4 to send :80 http requests directly to the mod_perl server, and have :443 https requests get verified thru the mod_ssl server which then also get sent to the mod_perl server at 192.168.7.10 (HTML::Mason needed to do the work). can this be done? am i barking up the wrong tree? is there a right tree to bark up? -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
perl timestamps
i didn't run into this until munging code via mod_perl and postgresql, so i figured this was a good place to ask a perl-generic question--if not, please point the way: print scalar localtime -123456789; "Tue Feb 1 20:26:51 1966" print scalar localtime -1234567890; "Mon Nov 17 18:28:30 1930" print scalar localtime -21; "Tue Jun 16 04:40:00 1903" so since linux (debian potato) can grok timestamps before 1970 (as negative values, which makes quite some sense) then does it not make sense for Time::Local to allow Time::Local::timelocal(0,0,0,7,11,1941) # 7 dec '41 or Time::Local::timelocal(0,0,0,30,9,1929) # 30 oct '29 ? or, what alternative is there (aside from munging the Time::Local code itself)? -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: [ANNOUNCE] Perl Templating Guide, v 0.9
On Wed, Aug 01, 2001 at 12:15:53AM -0700, Perrin Harkins wrote:
> http://perl.apache.org/features/tmpl-cmp.html
>
> The article "Choosing a Templating System" is now available at the above
> URL. This is the same material I presented at the O'Reilly conference,
> but a bit less rushed. It gives an overview of currently available
> templating tools and their basic features.
>
> This version is bound to have some bugs and general foolishness in it,
> so please send me an e-mail if you spot anything.
only flaw i saw was "it's" (it is) that shoulda been "its" (his,
hers, its):
HTML::Mason ...but has since become it's own unique animal...
s/'//
nice job! very informative. i feel better about using mason, and
still i wanna learn about axkit. :)
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: [off] giving call-back-func parameters...
On Tue, Jul 31, 2001 at 07:52:13PM +0300, raptor wrote:
> script.pl
> ===
> use Helper;
> my $callbackFunc = \&Helper::func;
> my $obj = new BigOne ( vals => $callbackFunc);
>
> BigOne.pm
> ==
> my $vals = shift;
>
> if (ref $vals eq 'CODE') {
>...
> my $kv = &$vals( id => $selected, dbh => $$self{dbh} );
>..
> };
>
>
> See $kv gets the return value from Helper::func(), everything is OK until
> I need to pass one more parameter to this function which I don't know in
> BigOne.pm but know at script.pl
my $callbackFunc = sub { &Helper::func(something=>$here, also=>$this, @_) }
maybe?
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Apache::DBI
On Sat, Aug 04, 2001 at 09:32:43PM +0530, Mithun Bhattacharya wrote:
> Shakes his head and hopes you will someday get enlightened as to the
> purpose of CPAN.
>
>
> > CPAN is great for red hat users (for example) who don't mind breaking things
let's not condescend too quickly -- when you finally come up for
air you might just get the bends...
here's my level of enlightenment on the purpose of cpan -- see if
i'm off (and if so, please illuminate):
cpan is where you can get perl modules. install the CPAN perl
module itself and you have handy command-line access to
downloading, building, testing and installing any perl module
you could care to shake a stick at.
this will cause no more problems on just about any linux distro
than doing a normal rpm install.
but if you're on debian, you're bypassing debian's advanced
packaging tool with all its inter-dependency info. on debian we
can get the appropriate version of package ABC /for our system/
(old-fashioned/anal "stable" [that's where you find me] vs
wanderlust-driven "testing" vs bleeding-edge "unstable"). with
direct cpan access i'm not sure there's a way to download the old
version of module XYZ that utilizes the old QRS libraries i've
got on my system. (it may be possible, but debian packages take
care of all that for me, saving me lots of learning curve, if it
exists.)
this is an advantage we debianites enjoy, and it's hard to
explain to others.
apt-get install libxml-perl libapache-ssi-perl libhtml-mason-perl
at one time, the system setup i've got right now, was
state-of-the-art, somewhere. my system is basically a snapshot of
that moment in time. with apt-get, instead of the current latest
and greatest -- which might force me to upgrade something
significant before i'm ready -- i'd get the packages that works
with my current system.
unless i'm wrong.
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Apache=SCALAR(?????)
On Fri, Jul 27, 2001 at 04:04:54PM -0700, Jeffrey W. Baker wrote: > > > On Fri, 27 Jul 2001, Greg Lontok wrote: > > > hello, > > > > I recently changed a username/password check script to mod_perl, however > > when under mod_perl, I noticed that failed logins with the correct username > > and password combination show the password in the log as Apache=SCALAR(???), > > i.e. Apache=SCALAR(0x2d9f74). What is mod_perl doing here to my password > > parameter. > > This is a basic Perl question. "Apache=SCALAR(0xcafebabe)" means that the > thing you printed is scalar reference to an object, blessed into the > Apache class, and its memory address is 0xcafebabe. meaning, more or less, somewhere you're doing this -- package Apache; my $item; print \$item; or use Apache; my $something = \$Apache::patricularGizmo; print $something; or use Apache; print Apache->pickAMethod($value,@list); # which returns a scalar ref or... :} -- I'd concentrate on "living in the now" because it is fun and on building a better world because it is possible. - Tod Steward [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Apache::DBI
On Thu, Jul 26, 2001 at 07:48:14AM -0600, Castellon, Francisco wrote: > Does anyone know if Apache::DBI is included with mod_perl? if not > could someone tell me where i could get it from? if you're using DEBIAN, you find it like this: $ dpkg -S Apache::DBI libapache-dbi-perl: /usr/share/man/man3/Apache::DBI.3pm.gz libapache-dbilogger-perl: /usr/man/man3/Apache::DBILogger.3pm.gz so (as root) you'd just # apt-get install libapache-dbi-perl and you're off to the races. -- I'd concentrate on "living in the now" because it is fun and on building a better world because it is possible. - Tod Steward [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: section syntax--where's tfm?
"Randal L. Schwartz" wrote: > > >>>>> "will" == will trillich <[EMAIL PROTECTED]> writes: > > will> http://perl.apache.org/guide/config.html mentions this type of > will> thing in passing, but surely there's an in-depth > will> "how-this-works" somewhere... > > will> > will> Order allow,deny > will> Allow from all > will> > > Uh, actually, not to solve your smaller problem, but to solve > your bigger problem instead: > > STOP LIMITING THE LIMITS. > > Almost *all* usage of is *wrong*. Just leave it off. (ow. no need to shout! :) i'd done that because i wasn't able to post at all, until i'd added allow everything at one time. -- mailto:[EMAIL PROTECTED] http://www.dontUthink.com/
Re: Error in Perl code: Can't locate Apache/Cookie.pm in @INC
On Tue, Jul 17, 2001 at 09:42:00PM +0200, Gerald Richter wrote: > > mod_perl as a DSO; can someone point me in the right direction to get the > > other modules loaded or what I didn't do that I needed to do to make the > > active? > > > > Put a > > PerlModule Apache::Cookie > PerlModule Apache::Registry > > etc. > > in your httpd.conf or, use the "+" shortcut -- PerlHandler +HTML::Mason::ApacheHandler (note the prefixed "+") same as PerlModule HTML::Mason::ApacheHandler PerlHandler HTML::Mason::ApacheHandler -- I'd concentrate on "living in the now" because it is fun and on building a better world because it is possible. - Tod Steward [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
section syntax--where's tfm?
this almost works. but i can't find the docs explaining why not:
#httpd.conf
use HTML::Mason::ApacheHandler ();
use Apache::Constants ();
require '/var/www/mtinker/mason.pl';
$VirtualHost{"127.0.0.1"} = [
{
DocumentRoot => '/var/www',
Alias => '/icons/ /usr/share/apache/icons/',
FilesMatch => {
'(\.html?|\.md|\.mason|^[^\.]+)$' => {
SetHandler => 'perl-script',
PerlHandler => 'HTML::Mason::ApacheHandler',
},
'(\.mc$)' => {
SetHandler => 'perl-script',
PerlHandler => 'Apache::Constants::NOT_FOUND',
},
},
Location => {
'/mtinker/' => {
# PerlRequre => '/var/www/mtinker/mason.pl',
SetHandler => 'perl-script',
PerlHandler => 'tinker::mason::handler',
},
'/' => {
Limit => {
METHODS => 'GET POST',
Order => 'allow,deny', # WTF? no workee
Allow => 'from any', # WTF? no workee
},
},
},
},
# {
# another virtual host config here, eventually...
# },
];
http://perl.apache.org/guide/config.html mentions this type of
thing in passing, but surely there's an in-depth
"how-this-works" somewhere...
Order allow,deny
Allow from all
how would we know to translate that to
...
Limit => {
METHODS => 'GET POST',
Order => 'allow,deny',
Allow => 'from all',
},
instead of to
Limit => {
'GET POST' => {
Order => 'allow,deny',
Allow => 'from all',
}
}
for example? where's the blinkin' manual? or maybe someone has a
large perl config that the rest of us can glean from? hmm?
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
On Wed, Jun 27, 2001 at 10:59:16AM -0700, Rob Bloodgood wrote:
> > me, on the other hand, i don't see the problem with
> >
> > on incoming request
> > if has-cookie 'session'
> > {
> > update serverside 'accesstime' for session[this] to NOW
>
> Oh yeah? HOW???
$dbh->do("update sesssion_rec set visit = ? where id = ?",time,$session{id});
or maybe even just
$session{when} = time;
> > if not-modified-since
> > report same
> > else {
> > send headers w/ cookie
> > generate page
> > }
> > }
> > else
> > redirect to login page
> >
> > doesn't look unmanageable to me (until someone shows me the
> > light, of course)...?
>
> How many sessions/day are you running? How big is your DB? How much
> processor do you have to throw at this? (these are the hurdles for storing
> serverside info).
maybe it doesn't scale well, i don't know; it works well for our
purposes. at least you don't have to worry about being unable to
send a new cookie on 'no-changes-since...'. just use the session
id of the existing cookie to 'touch' the session record, updating
the timestamp.
but maybe it's trickier than that for some cases...?
> OTOH, what *benefit* is derived from storing all of this stuff serverside?
"all" in this case is 'timestamp-of-last-request'.
--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
setting httpd cookie domains
- Forwarded message from will trillich <[EMAIL PROTECTED]> - From: will trillich <[EMAIL PROTECTED]> Date: Tue, 1 May 2001 21:58:41 -0500 To: [EMAIL PROTECTED] Subject: OT -- setting httpd cookies Pointers welcome, of course, to which FM i should R: In setting cookies via cgi or whatever, there's rules on having to include at least two portions of your domain in the cookie, such as for hyperarchive.lcs.mit.edu the minimum domain allowable would be mit.edu, right? But you still have to put the two dots in, as for example, ".mit.edu". Would this allow cookies from "smith.mit.edu" and "www.mit.edu" AND "mit.edu" to be set properly? Or would they go into the bit bucket, for greenpeace-friendly recycling? Or for more hypothetical instance, cpu.subnet.org.tld can set cookies with domain=".org.tld" and so can "www.org.tld" but can plain old prefix-challenged "org.tld" work cookies, in this case? -- I'd concentrate on "living in the now" because it is fun and on building a better world because it is possible. - Tod Steward [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
On Mon, Jun 25, 2001 at 04:54:59PM -0700, Rob Bloodgood wrote:
> > > maybe storing 'last-access-time' on the server, instead of in
> > > the client-side, via cookie, would solve this snafu?
> >
> > But if you want to give out a new cookie on every request ?
> > How would you prevent them from copying or tampering with the contents?
> > a MD5-hash would stop them from changing values, but they could
> > still copy the cookie,
> > so the next idea is timeouts, and when you use timeouts it would
> > be nice if the user
> > don't have to login every couple of minutes, but would get a new
> > valid cookie automaticly...
>
> Aside from the fact that a server-side tracking system is bound to become
> incredibly unmanageable, very quickly, in terms of server-side storage...
>
> One of the methods I've used is to include a timestamp in the user's info
> (incl the MD5 hash? see the Eagle for Encryption of Cookies w/ MD5).
>
> THEN, when deparsing the cookie, DELETE it if the timestamp is too old.
>
> THEN, you either have a valid, non-timed out session, or no session at all
> (which is what you were worrying about in the first place, no?). If your
> system is based on session LENGTH (ie this ticket is good for one hour from
> last access), all you have to do is re-set the timestamp to the current
> time.
but he's saying that he can't send a cookie AND do the
'not-changed-since' thing.
me, on the other hand, i don't see the problem with
on incoming request
if has-cookie 'session'
{
update serverside 'accesstime' for session[this] to NOW
if not-modified-since
report same
else {
send headers w/ cookie
generate page
}
}
else
redirect to login page
doesn't look unmanageable to me (until someone shows me the
light, of course)...?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: SSI Lost with Mod Perl?
On Tue, Jun 26, 2001 at 01:06:06AM -0400, Brooklyn Linux Solutions CEO wrote:
>
> I've given Filter and SSI a shot according to the perldocs.
>
> It didn't work. I stated to hhack on some of the problems, which first involved
> in the make install depositing them in the wrong diretory, and then they SSI
> needed use Apache::Filter statements added.
have you tried HTML::Mason yet? it's got serious power, but you
can have some quickie modular sites up in a jiffy.
.../autohandler:
<& SELF:title &>
<& SELF:heading &>
<& SELF:navbar &>
<% $body %>
<& SELF:footer &>
<%method title>Welcome
<%method heading>Welcome to our site
<%method navbar><% &my_navbar() %>
<%method footer>It is now <% scalar localtime %> at our offices
<%once>
sub my_navbar {
...
}
<%init>
% my $body = $m->comp_next(); # set dependent variables first
.../search.md:
Search:<& searchform,query=>$query &>
% if ($query) {
Found:<% &list($query) %>
% }
<%method searchform>
<%method title>Search <% $recs %>
<%method heading><& SELF:title &>
<%once>
sub list {
...
}
<%shared>
my $recs = ... ? 'Products' : 'Services';
<%args>
$query => undef
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Directory Restrictions
On Wed, Jun 27, 2001 at 08:52:10AM -0500, Adekunle Olonoh wrote:
>
> > I found it, quite be accident in the Eagle Book
> >
> > Lost the page number, but it was in Chapter 4.
>
> There's some discussion in the last paragraph of page 86.
>
>
> > anybody got a more specific pointer to help us fuzzy searchers
> > find 'how to have mod_perl handle directory requests'?
>
> Hopefully this should be a pretty decent start:
> sub handler {
> if ($r->content_type eq 'httpd/unix-directory') {
okay -- but if you want some of your site to be indexed by the
standard mod_autoindex, yet have mod_perl intervene for certain
subtrees, you'll find that mod_perl never gets a chance at it
because the mod_autoindex gadjets catch it at an earlier stage.
i think.
what stage would that happen to be? and how do we configure
httpd.conf to Do What We Want?
(i think, that if you disable mod_autoindex, that you can have
mod_perl handle directories just as you say. but there's some
magic involved in running BOTH mod_autoindex and having mod_perl
do a directory now and then. i think. maybe.)
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Directory Restrictions
On Tue, Jun 26, 2001 at 01:00:00AM -0400, Brooklyn Linux Solutions CEO wrote: > I found it, quite be accident in the Eagle Book > > Lost the page number, but it was in Chapter 4. i know i ran across something like that at once time myself, but scanning chapter 4 for twenty minutes didn't find it. (not that i'm error-free when it comes to finding things, tho... :) anybody got a more specific pointer to help us fuzzy searchers find 'how to have mod_perl handle directory requests'? -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Requests using If-Modified-Since cause response Set-Cookie to be discarded
On Fri, Jun 22, 2001 at 12:32:28PM -0700, Doug MacEachern wrote: > quoting his email: > "The cookie records, in part, the time of the last access to > the site. Therefore for each access the cookie is updated." > > that to me sounds like a header "which may have changed independently of > the entity's Last-Modified date". maybe storing 'last-access-time' on the server, instead of in the client-side, via cookie, would solve this snafu? -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Directory Restrictions
Brooklyn Linux Solutions CEO wrote: > > One thing that is not clear in my mind is the type of > page which is sent back with a directory index. > > A directory index is of what mime type? i'm sure it's documented somewhere -- but mime types are main/secondary (text/html, image/gif) and the directory mime type is either /directory or directory/ but you'll have to do something fancier than just look for that -- i think it's a different phase in the apache sequence where the directories are handled. i found that mod_index was intervening BEFORE i got to any apache handler (i don't recall which phase, tho)... anybody got a handy link to point us in the right direction here? how can you have mod_perl intercept the directory listing? == another thought: #httpd.conf DirectoryIndex index.md index.cgi index.html /path/to/registry/index.pl -- mailto:[EMAIL PROTECTED] http://www.dontUthink.com/
Re: Directory Restrictions
On Sat, Jun 23, 2001 at 11:10:07PM -0400, Brooklyn Linux Solutions CEO wrote:
>
> I've been working on a mod_perl implimentation which
> does the following.
...
> I have something like this running on the top directory:
>
>
> sub handler{
> my $r = shift;
> return DECLINED if ($r->uri() =~ /top/home.html);
> return DECLINED if ($r->uri() =~ /top/login.html);
> return DECLINED if ($r->uri() =~ /top/lower_dir1);
> return DECLINED if ($r->uri() =~ /top/lower_dir2);
> return DECLINED if (!$r->content_type('text/html));
> return DECLINED if ($r->content_type('images/gif));
i bet you mistyped some of that...
val =~ /pattern/flags
maybe something more like:
return DECLINED
if ($r->uri() =~ m{/top/((home|login).html|lower_dir[12])});
> It's doing an internal redirect when they are autorized for on of the
> lower directories, but the graphics are still now getting through
> to the top if I remove the DECLINED content_type 'text/html'. But when
> I leave it in, they seem to have access to the directory access.
hmm -- "! text/html" should make "images/gif" redundant, i'd
think. anybody got a pointer, here?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Apache::AuthDBI
On Tue, Jun 19, 2001 at 10:38:01AM -0700, Alan E. Derhaag wrote:
> "Christian Heiss" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I'm using Apache::AuthDBI to verifying the users on my web site.
> > then I put it in the database with:
> >
>
> > >my $sql = "INSERT INTO VALUES($userid, $groupid, $pass, ...);
> > of course, before I'm using the quote funktion ($dbh->quote($userid)...)...
maybe do this instead:
@vars = ($alpha,$bravo,$charlie,$delta);
my $sql = "insert into sometable values(" . (join '.',('?') x @vars) . ")";
$sth = $dbh->prepare($sql);
$sth->execute(@vars);
$sth->finish();
just a suggestion...
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: CGI::Cookie vs Apache::Cookie -- help?
On Mon, Jun 18, 2001 at 07:18:56AM +0200, Per Einar wrote:
>
> - Original Message -
> From: "will trillich" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 18, 2001 7:09 AM
> Subject: Re: CGI::Cookie vs Apache::Cookie -- help?
> > what does $cookie->bake do (add set-cookie header) that
> > $r->header_out('set-cookie'=>$cookie) (add set-cookie header)
> > does not?
> >
> > [ and why ain't that mentioned in the manual? ]
>
> As someone else stated, bake() actually sends a Set-Cookie header, but with
> $cookie->as_string and not just $cookie (which is an instance of
> Apache::Cookie). When you're just sending $cookie you're sending an object
> reference.
>
> Per Einar Ellefsen
> [EMAIL PROTECTED]
my grok quotient has grown considerably. thanks!
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: CGI::Cookie vs Apache::Cookie -- help?
On Sun, Jun 17, 2001 at 11:14:23PM -0400, Chris Winters wrote:
> * will trillich ([EMAIL PROTECTED]) [010617 23:04]:
> > $r->log_error( qq(...id=$ID, sending cookie) );
--this outputs the string i'm hoping for, into the log file.
> > my $cookie =
> > Apache::Cookie->new( $r,
> > -name => $cookie_name,
> > -value => $ID ,
> > -domain => $r->hostname,
> > -path => '/' ,
> > );
> > $r->header_out('Set-Cookie', => $cookie);
> From 'perldoc Apache::Cookie'
>
>bake
>Put cookie in the oven to bake. (Add a Set-Cookie
>header to the outgoing headers table.)
>
>$cookie->bake;
what does $cookie->bake do (add set-cookie header) that
$r->header_out('set-cookie'=>$cookie) (add set-cookie header)
does not?
[ and why ain't that mentioned in the manual? ]
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: [OT] Is this feasible in Perl??
On Wed, Jun 13, 2001 at 06:57:45AM +0800, Gunther Birznieks wrote: > My experience is that architecturally Perl cannot handle this. You should > switch to Java and use an Enterprise Java Bean to do all this for you. you must have an interesting sense of humor. -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
CGI::Cookie vs Apache::Cookie -- help?
On Sat, Jun 16, 2001 at 12:58:14AM +0200, Nenad wrote:
> package Apache::PermanentTicketRenewer
> my Counter;
> sub handler {
> my $r = shift;
>
> $Counter += 1;
> my $cookie = CGI::Cookie->new(-name => 'Ticket',
> -path => '/',
> -domain => '.my.com',
> -expires => '+1M',
> -value => { 'ID' => $Counter }
>);
mine is similar:
$r->log_error( qq(...id=$ID, sending cookie) );
my $cookie =
Apache::Cookie->new( $r,
-name => $cookie_name,
-value => $ID ,
-domain => $r->hostname,
-path => '/' ,
);
$r->header_out('Set-Cookie', => $cookie);
which sets a cookie value of "SCALAR(0x863c9f8)" instead of the
$ID string that shows up in the log, which is
...id=483dd0e2202accce6d4d3e07d976bfdc, sending cookie
in the original ticket example above, -value is a hashref:
-value => { ID => $ID }
instead of
-value => $ID
as the Apache::Cookie manpage suggests (a plain scalar value).
this worked just fine with CGI::Cookie (without the $r, of
course) -- can't get it to return the actual scalar value with
Apache::Cookie...
ideas? help!
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
On Sun, Jun 10, 2001 at 10:36:17PM +0800, Gunther Birznieks wrote: > At 08:59 AM 6/8/2001 -0500, will trillich wrote: > >which of the existing paradigms will the widget farm most > >closely resemble? and what are your expectations for tradeoff in > >functionality/modularity-vs-performance? > > 1) What do you mean by your first question? if i was going to minimize a future learning curve, i'd like to be able to jump aboard the widget farm already armed with knowledge of how to do something similar. if it's nothing at all like mason, but similar to axkit, then (if i expect to be an ardent fan of the widget attack) i'd be better off pursuing axkit. for example. > 2) I believe there is nothing being done in the widget farm that would > really hinder performance other than being objects with methods. Really > without a good object structure then a widget farm is wholly useless. you're definitely right, there. i'm just noticing that several templating methods add "molasses in january" effects to the rendering of some pages. of course, there may be more to blame in the instance of implementation, than in the implementation itself... thanks for your replies -- we're leaning towards axkit or mason at the moment-- -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
On Fri, Jun 08, 2001 at 06:52:14PM +0800, Gunther Birznieks wrote: > At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: > > > HTML::Embperl > > > >For me, this has one major win over the other toolkits: auto form > >population from a hash. The online mortgage application system I > >wrote has about 1,800 form fields, which have to be populated with > >data from a database. By making the form fields match DB column > >names, I can reduce the code to do this to: > > > >my $data = $dbh->fetchrow_hashref($query); > >%fdat = (%fdat, %$data); > > > >Embperl then parses the form and populates it with the matching > >name=>value pairs in %fdat, including select options. Beautiful! > > Not that it's a reality now, but this is one of the things that the Perl > Widget Library project on source forge is hoping to accomplish for template > languages. It's a cross template way of organizing form information and map > it to db fields. > > The reality is that there are many fields that cannot map easily 1-1 to a > database as you say. eg a date in a database is usually a date field. But > in a form, it might be a combination of 3 form fields (dropdown for month, > year and day separately). which of the existing paradigms will the widget farm most closely resemble? and what are your expectations for tradeoff in functionality/modularity-vs-performance? -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
templating benchmarks...
On Thu, Jun 07, 2001 at 06:48:38AM +0200, Gerald Richter wrote: > > regarding the tools that dovetail into the mod_perl paradigm, > > who's got a comparison over relative performance (and other > > strengths/weaknesses) of various templating methods? > > There are various discussions on the mod_perl list about this topic in the > past (so take a look at the archives). Also there was an start to write such > a comparsion, but I am not aware that anybody has really finished it. The > only benchmarks I know are from Joshua. I append his mail below. > > NOTE: While the hello.xxx benchmarks only prints "Hello world", so they only > measures the startup overhead of the toolkit, the h2000.xxx tests tends a > little bit more towards a real application. this is interesting information -- perhaps misleading to use the microscopic "hello world" but still it gives a starting point: here i sorted by hits-per-second > Test Name Test File Hits/sec Bytes/Hit > -- -- -- > HTML statichello.html 1158.4 311 bytes > mod_include SSIhello.shtm 996.6 198 bytes > mod_caucho JSP hello.jsp 860.6 230 bytes > mod_perl handler hello.benc 852.6 196 bytes > mod_php PHPhello.php 734.8 225 bytes > Apache::Registry v2.01 CGI Raw hello_raw. 706.4 52 bytes > Apache::Dispatch v0.08 handler hello/worl 656.1 196 bytes > HTML::Template v2.0hello.htmp 567.2 198 bytes > Apache::SSI v2.16 hello.shtm 559.4 199 bytes > Template v2.00 Toolkit hello.tt522.1 198 bytes > Apache::Registry v2.01 CGI.pm hello.reg 458.5 216 bytes > HTML::Embperl v2.0a18 hello.epl 458.2 219 bytes > Apache::ASP v2.07 hello.asp 390.6 241 bytes > Apache::ePerl hello.eper 344.8 217 bytes > HTML::Mason v0.895 hello.mas 365.3 197 bytes i bet CGI would be 200.0 or so... ? and here's the "handler actualy does some work" set: > mod_caucho JSP 2000h2000.jsp 328.9 28964 byte > mod_php PHP 2000 h2000.php 261.8 28865 byte > HTML::Embperl v2.0a18 2000 h2000.epl 247.3 28809 byte > Apache::ASP v2.07 2000 h2000.asp 228.0 28997 byte > HTML::Mason v0.895 2000h2000.mas 222.9 28798 byte > Template v2.00 Toolkit 2000h2000.tt 55.6 2 byte wow. template toolkil took a big hit, there. (no mod_perl on this list? hmm!) -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us! -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
On Fri, Jun 08, 2001 at 10:49:39AM +0800, Stas Bekman wrote: > This is your "ultimate" answer :) : > > Choosing a Templating System. > http://conferences.oreillynet.com/cs/os2001/view/e_sess/1263 > > Hopefully Perrin will release his paper close to the conference. looking forward to that! thanks. -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, "Some Came Running" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
comparison of templating methods?
okay -- there's code (mod_perl modules) and there's html, and we should keep them separate -- which gives rise to templates... i've heard of Apache::PageKit Apache::Template AxKit eXtropia? HTML::Mason HTML::Embperl HTML::Template OpenBedrock Template-Toolkit XPathScript XSLT regarding the tools that dovetail into the mod_perl paradigm, who's got a comparison over relative performance (and other strengths/weaknesses) of various templating methods? -- #95: We are waking up and linking to each other. We are watching. But we are not waiting. -- www.cluetrain.com [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: looking for cited document WRT web testers
On Tue, Jun 05, 2001 at 01:50:47PM -0400, Brian Reichert wrote: > I hope I'm not barking up the wrong tree, but I could not find this > in the archive. > > I could have _sworn_ that within the last several weeks, someone > had posted here a URL to a document that described, in a handy way, > information for web testers WRT the sorts of details they really > need to supply to the developers to be useful. > > Ie. 'the web page gives me errors' is inadequate; real details are > needed (browser version, what actions were taken, etc.). (The > document in question actually gave some background info as to why > the details are helpful...) > > Does anyone know what I'm talking about? Even if you can't recall > such post to this list, a recommendation of such a document would > be welcome. > > I know the details myself, and could write such a document, but > this author had done a good job... > > Feel free to reply to me off-list, if you don't want to clog > everyone's mailboxes... i saw something recently (may not have been mod_perl) about what statistics webmasters might find useful -- a whole bunch of things to check for, measure by, etc. seems like it may even have been a static web page Out There Somewhere. of course, i can't find it either. damn web's too darn big. -- #95: We are waking up and linking to each other. We are watching. But we are not waiting. -- www.cluetrain.com [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Practical examples of mod_perl Method handlers?
On Tue, Jun 05, 2001 at 04:30:47PM -0700, Randy J. Ray wrote: > Are there any CPAN modules for Apache that are examples of writing a method > handler? The docs in the manpage, the book, and the mod_perl guide are > pretty much all the same (brief) text. A good example would help a great > deal. Thanks. you could go to the source (may the schwartz be with you) for an neat mod_perl concept -- tracking web hits via SQL database... http://webtechniques.com/archives/2000/04/perl/index.shtml i originaly did cut-and-paste and the sucker nearly worked for me right out of the box. i've since tweaked the heck out of it, for my own nefarious purposes... -- #95: We are waking up and linking to each other. We are watching. But we are not waiting. -- www.cluetrain.com [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: HTTP 1.1
On Mon, Jun 04, 2001 at 07:53:59PM +0400, Ruslan V. Sulakov wrote:
> Strange numbers appeares, when I use HTTP 1.1 protocol to get response from my
>mod_perl server.
> The test.pl script:
> use strict;
> use Apache::Request();
> my $r = shift;
> my $apr = Apache::Request->new($r);
> $apr->send_http_header('text/html');
> print "1234567";
>
> Now look to HTTP 1.1. response of this script:
> # telnet xx.xx.ru 81
> Trying xxx.xxx.xxx.xxx...
> Connected to xx.xx.ru.
> Escape character is '^]'.
> GET /test.pl HTTP/1.1
> Accept: */*
> Host: xx.xx.ru
>
> HTTP/1.1 200 OK
> Date: Mon, 04 Jun 2001 14:49:24 GMT
> Server: Apache/1.3.12 (Unix) mod_perl/1.24
> Transfer-Encoding: chunked
> Content-Type: text/html
>
> 1
> 1234567
> 0
> What does mean number 1 before line "1234567"? And what does mean 0 after all?
> Is there a way to cut off the line with number "1" and cut off the line with number
>"0"?
> I need only line "1234567" in response! It is vital for me!
>
>
> Now look what will be, if I ask HTTP version 1.0:
> bsd2# telnet xx.xx.ru 80
> Trying 212.188.13.65...
> Connected to xx.xx.ru.
> Escape character is '^]'.
> GET /test.pl HTTP/1.0
> Accept: */*
> Host: xx.xx.ru
>
> HTTP/1.1 200 OK
> Date: Mon, 04 Jun 2001 15:39:16 GMT
> Server: Apache/1.3.9 (Unix) mod_perl/1.21 rus/PL28.18
> Connection: close
> Content-Type: text/html; charset=koi8-r
>
> 1234567
>
>
> Thats all right with HTTP/1.0! No additional lines in output and no Header
>"Transfer-Encoding: chunked" in response.
>
> But I need , it to be all right in case of HTTP/1.1 !
>
> Is there any ideas?
here's the key the the answer you're looking for:
Transfer-Encoding: chunked
for wise browsing software, these numbers are used in
re-constructing the original html from the chunks as they
arrive.
if you're just sending your stuff to an average joe running a
standard web browser, they should all understand this stuff out
of the box. if you're doing something fancy (proxy filter,
maybe?) perhaps you need to check the specs for the HTTP/1.1
protocols and accomodate them. :)
--
#95: We are waking up and linking to each other. We are watching. But
we are not waiting. -- www.cluetrain.com
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: authorization and mod_perl
On Wed, May 16, 2001 at 01:39:45PM -0400, barries wrote:
> On Wed, May 16, 2001 at 12:07:28PM -0400, Vivek Khera wrote:
> >
> > I don't think location takes a glob pattern.
>
> A nit: it can. , and can all take
> shell-like globs using ?, *, and []/[!...]/[^...] operators, looks like.
> No equivalent to {a,b,c} alternation, AFAICS.
according to /usr/share/doc/apache-doc/manual/mod/core.html,
# matches exactly
# matches filename glob
# matches full regex, with tilde
# matches full regex
and similar for and
--
What do I need manners for? I already got me a wife.
-- Adam Pontipee, "Seven Brides for Seven Brothers"
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: Global variables
On Wed, May 16, 2001 at 07:13:22AM +0200, Bjoern wrote: > i want to define a global variable which is also present in subroutines > coded in > extra perl modules. > I tried this "our $test;" but amod_perl tells me following "Global > symbol "$test" requires explicit package name" I know, this is a > question which may be not right here ! > I don`t want to use the perlmodule CGI !! > > I hope some persons can help me, primarily, global variables are looked down upon. but like the error message says, you can explicitly name any global like this: $The::Meaning::Of::Life::The::Universe::And::Everything = 42; you might also try use vars($Something); $Something = &whatever(); but you should probably use closures and references instead. (i'll be re-coding my website to avoid globals in the next few weeks, now that i understand what i just said, there. :) see also http://thingy.kcilink.com/modperlguide/porting/Dynamically_updating_configurati.html -- What do I need manners for? I already got me a wife. -- Adam Pontipee, "Seven Brides for Seven Brothers" [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: perl-based authentication
On Thu, May 10, 2001 at 11:50:31PM -0600, Mark Holt wrote: > parsing the .htaccess files is what I'm trying to avoid. I want the standard apache > module to do that. I just want to control *when*. have you considered breaking up the apache instances, maybe? might be a bad idea, but i thot i'd suggest it... if paid-vs-free hosts are reasnably well-known at server startup, and there's not lots of changeover from one group to another, maybe you can break the server up into two instances? one for paid (looking at the .htaccess files) and another for freebies (ignore .htaccess files)... -- my other .signature is really witty. [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: authorization and mod_perl
On Wed, May 09, 2001 at 10:10:19AM -0500, John Saylor wrote: > Perhaps this is obvious, or said somewhere that I haven't looked; but > I'm having trouble figuring it out. it feels like "everything is obvious to everyone but me" doesn't it? :) > What I want is for a certain directory tree to be behind an > authorization handler; however, the content behind this directory tree > consists of handlers and aliases. And the authentication handler isn't > working with directives. > > > AuthName"foo control" > AuthTypeBasic > PerlAuthenHandlerApache::OK > PerlAuthzHanlderWW_authz > PerlSetVarMaskGeek > requireusermaskgeeky > presumably that's a typo: PerlAuthzHanlder ? (always a good idea to cut and paste from the actual source or actual output.) > I don't think it's even getting called. > > Do I need to push the code as a PerlChildInitHandler? i wouldn't think so. > Should I create the [empty] root directory in the htdocs tree as a place > holder for a directive? i tried that just to see, and it caused more trouble than it solved... > Is there some syntax error in my block? as is in your email, there is a typo: Hanlder ... > Should it work OK [I cribbed most of it from the eagle book]? i used the Apache::Ticket examples and learned that i needed to modify them for my purposes, but it worked with directives just fine, WITHOUT an empty directory to match. (in fact, creating such an empty directory interfered in a big way.) # TICKET / COOKIE stuff # restricted area needing ticket access SetHandler perl-script # handle content-generation (if we get in) PerlHandler +My::Handler # arewe allowed in? PerlAccessHandler Apache::TicketAccess PerlSetVar TicketDomain .testing-this-monster.com PerlSetVar TicketLogin http://www.testing-this-monster.com/login # TICKET server SetHandler perl-script PerlHandler +Apache::TicketMaster PerlSetVar TicketDomain .testing-this-monster.com PerlSetVar TicketExpires 20 # KEY server order allow,deny allow from 192.168.1 allow from 127.0.0.1 deny from all -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: Sections in Apache Config
On Mon, May 07, 2001 at 09:32:23PM -0400, Philippe M . Chiasson wrote:
> On Mon, May 07, 2001 at 05:35:57PM -0700, Jonathan Hilgeman wrote:
> > I've been trying to do this for some time but can't figure out how.
> >
> > UseCanonicalName Off
> >
> > if($HTTP_HOST =~ s/(?:www\.)?(.*)\.domain\.com//g)
> > {
> > $VirtualDocumentRoot = "/www/httpd/html/$1";
> > }
> > else
> > {
> > $VirtualDocumentRoot = '/www/httpd/html/%-3';
> > }
> > 1;
> >
> >
> Your problem is that this code is evaluated at startup-time, not request-time.
> So this means it will be run once globally, the regexp won't match and you just
> configure the default. There are many ways to do it.
>
> First, look at mod_vhost_alias http://httpd.apache.org/docs/mod/mod_vhost_alias.html.
> VirtualDocumentRoot /www/httpd/html/%0
>
> Would map requests to www.username.com to /www/httpd/html/www.username.com
> And for the username.com, you could simply use a symlink.
>
> Second, use mod_rewrite http://httpd.apache.org/docs/mod/mod_rewrite.html
> Something like :
>
> RewriteEngine on
> RewriteCond %{HTTP_HOST} ^(www\.)?[^.]+\.host\.com$
> RewriteRule ^(.+)%{HTTP_HOST}$1 [C]
> RewriteRule ^(www\.)?([^.]+)\.host\.com(.*) /www/httpd/html/$2$3
>
> Third, you could do it in mod_perl with a custom handler
>
>
> use Apache::Constants qw(:common);
> sub My::MassVHosting::handler {
> my $r = shift
> if($r->header_in('Host') =~ /^(www\.)?([^.]+)\.domain,com/)
s/,/\\./
> {
> $r->filename("/home/httpd/html/$2");
> $r->stat();
> return OK;
> }
> return Apache::Constants:;DECLINED;
s/;/:/
> }
>
> PerlTrancHandler My;;MassVHosting
s/;/:/g
> For more information about mod_per magic, consider getting the book or reading the
>guide
> http://perl.apache.org/guide/
>
> Hope this helps.
>
> P.S. I am not responsible for tyops ;-)
nice disclaimer... :)
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: [OT] Re: mod_perl subs defined, but don't exist? SOLVED mostly
On Fri, May 04, 2001 at 12:29:30AM -0500, Ken Williams wrote:
> [EMAIL PROTECTED] (will trillich) wrote:
> > >sub search {
> > >#
> > >{
> > >use CGI qw/:standard/;
> > >my $form = join '',
> > >map {
> > >hidden(
> > >-name => $_,
> > >-value => $arg->{$_},
> > >) . "\n"
> > >}
> > >grep(
> > >$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
> >
> >as is, the functions that follow (top-level 'sub xyz {}') get
> >screwy. code disappears.
> >
> >replace "and" with "&&" and all is well. boggles my mind.
>
>
> Well, as far as I can tell, the original code doesn't even compile
> because there aren't enough arguments to grep(). That's why I couldn't
> test it.
grep(
$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
, keys %$arg # note the leading comma...
)
aha -- so maybe "x and y and z , pdq" has lexical precedence
where the (z,pdq) parses higher, as in
x and y and (z , pdq)
versus what i expected, which was
(x and y and z) , pdq
hmm?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
Re: mod_perl subs defined, but don't exist? SOLVED mostly
On Thu, May 03, 2001 at 08:52:38PM -0500, Ken Williams wrote:
> I can't follow this test case. Your previous message had a test case,
> but it was way too big. Can you whittle this down into the smallest
> possible program that demonstrates something you don't understand, and
> post that? My guess is that you'll figure out the problem in the
> process, but if not, post it here.
i found the culprit, but it's like finding out that a butterfly
burned down your house. i still don't see how it's possible.
when i distill it, of course, the problem vanishes. but see
below--
> By the way, I don't think you mean $My::Debacle::handler{CODE}. If you
> look closely, you'll see that it's just a regular hash entry. I think
> you mean *{$My::Debacle::{handler}}{CODE}. That's the CODE component of
> a symbol table entry.
right. whoops. boy, that stuff gets deep, quick.
> If you have "Effective Perl Programming", look on page 239.
eagle book, camel book, but no "shiny ball book". yet. :)
> I know this stuff is hard to spot when you've been banging your head
> against it for days. For that, I recommend "Zen and the Art of
> Motorcycle Maintenance".
a very good read, that.
> [EMAIL PROTECTED] (will trillich) wrote:
> >okay, here was the problem.
> >
> >package My::Debacle;
> >
> >sub search {
> >#
> >{
> >use CGI qw/:standard/;
> >my $form = join '',
> >map {
> >hidden(
> >-name => $_,
> >-value => $arg->{$_},
> >) . "\n"
> >}
> >grep(
> >$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
as is, the functions that follow (top-level 'sub xyz {}') get
screwy. code disappears.
replace "and" with "&&" and all is well. boggles my mind.
> >, keys %$arg
> >)
> >;
> >#
> >}
> >#
> >}
> >
> >sub this { # ...
> >}
> >sub that { # ...
> >}
> >sub something_else { # ...
> >}
> >sub whatever_the_hell { # ...
> >}
> >sub handler { # ...
> >}
with 'and' *{$My::Debacle::{handler}}{CODE} doesn't exist.
i've got a similar snag in a different module, now, where defined
subs are disappearing. but i can't trace it to a stray 'and'
here... must be something deeper?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
Re: mod_perl subs defined, but don't exist? SOLVED mostly
On Thu, May 03, 2001 at 01:19:45AM -0500, will trillich wrote:
> On Thu, May 03, 2001 at 12:29:53AM -0500, will trillich wrote:
> > long version--
> >
> > I have a subroutine that IS DEFINED, but it's not showing up as
> > defined. I used the *Symbol::Table::name{CODE} method myself and
> > sure enough, there's no CODE for the defined subroutine...
>
> [snip]
>
> > ANY wild-ass guesses would be appreciated. (Do i win a prize for
> > the most difficulty with a simple situation? Or at least an
> > honorable mention for most belligerent refusal to move on and get
> > a life?)
> >
> > ###
> >
> > short version--
> >
> > WTF?
>
> how can a defined subroutine NOT have any code in the symbol
> table? grr! this is quite a puzzle...
okay, here was the problem.
package My::Debacle;
sub search {
#
{
use CGI qw/:standard/;
my $form = join '',
map {
hidden(
-name => $_,
-value => $arg->{$_},
) . "\n"
}
grep(
$arg->{$_} and ($_ ne 'd') and ($_ ne 'go')
, keys %$arg
)
;
#
}
#
}
sub this { # ...
}
sub that { # ...
}
sub something_else { # ...
}
sub whatever_the_hell { # ...
}
sub handler { # ...
}
can you spot the problem?
with that, poof! $My::Debacle::handler{CODE} doesn't exist.
WHY?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: HTTP::Cookies problem
On Thu, May 03, 2001 at 12:54:46PM +0200, Jonas Nordstr?m wrote:
> How can I copy cookies from an incoming request to a LWP-request and also
> add a custom cookie? Can I use HTTP::Cookies?
>
> I use:
> $request->header('Cookie' => $r->header_in("Cookie"));
> and it works fine, but now I want to add a cookie that the client didn't
> send.
> Can I use $cookie_jar->set_cookie() and then
> $cookie_jar->add_cookie_header($request);? But what happens with the
> original cookies?
so you just wanna forward a cookie? i'm not a cookie expert
(and how, look at my recent desperate posts) but i'd say
you can send whatever cookie you want, for whatever nefarious
purposes you'd like.
$req->header('Cookie' => $r->header_in('Cookie'));
$req->header('Cookie' => &my_new_cookie_monster( $something ));
as far as 'what happens with the original cookies' they stay with
the user's browser, until they expire (if an expire date was
given) or end-of-session (when browser is quit, if no expire was
given).
i think the answer to your question is, you can chain several
cookie headers on via the same ->header('Cookie' => ...) call.
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: mod_perl subs defined, but DON'T EXIST? wtf?!
On Thu, May 03, 2001 at 12:29:53AM -0500, will trillich wrote:
> long version--
>
> I have a subroutine that IS DEFINED, but it's not showing up as
> defined. I used the *Symbol::Table::name{CODE} method myself and
> sure enough, there's no CODE for the defined subroutine...
[snip]
> ANY wild-ass guesses would be appreciated. (Do i win a prize for
> the most difficulty with a simple situation? Or at least an
> honorable mention for most belligerent refusal to move on and get
> a life?)
>
> ###
>
> short version--
>
> WTF?
how can a defined subroutine NOT have any code in the symbol
table? grr! this is quite a puzzle...
my version info is as follows, in case it's germane:
$ apache -v
Server version: Apache/1.3.9 (Unix) Debian/GNU
Server built: Apr 30 2000 12:54:24
$ cat /etc/debian_version
2.2
$ perl -MTie::DBI -MCGI::Cookie -MMD5 -MLWP::Simple \
-MApache::File -MApache::URI -MApache \
-e 'print map {s/.pm$//;s%/%::%g;"$_ => ".${$_."::VERSION"}."\n"} sort keys
%INC'
Apache => 1.26
Apache::Connection => 1.00
Apache::Constants => 1.09
Apache::Constants::Exports =>
Apache::File => 1.01
Apache::Server => 1.01
Apache::URI => 1.00
AutoLoader =>
CGI::Cookie => 1.20
CGI::Util => 1.2
Carp =>
DBI => 1.13
Digest::MD5 => 2.09
DynaLoader => 1.03
Exporter =>
Fcntl => 1.03
HTTP::Status => 1.26
LWP::Simple => 1.34
MD5 => 2.01
Tie::DBI => 0.91
mod_perl => 1.2103
overload =>
strict => 1.01
vars =>
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
mod_perl subs defined, but DON'T EXIST? wtf?!
long version--
okay, i'm confused, and this time it's not related to cookies.
it happens to be the same bloinkin' project, but this time it's
perl in general, that's got me baffled...
if have a subroutine that's defined, but it's not showing up as
defined. i used the *Symbol::Table::name{CODE} method myself and
sure enough, there's no CODE for the defined subroutine...
here's my debug snippet, in context--
###
package My::Access;
# File: My/Access.pm
use strict;
use Apache::Constants qw(OK SERVER_ERROR);
use Apache::TicketTool;
use Apache::Log;
sub handler {
my $r = shift;
{
no strict;
# see camel book, page 282
my $x = '';
my @key = qw(
SCALAR ARRAY HASH
CODE FILEHANDLE
); # ignore GLOB, PACKAGE, NAME
foreach my $item ( sort keys %My::Access:: ) {
my $descr = '';
foreach ( @key ) {
$descr .= "\t$_\n"
if defined( *{$item}{$_} );
}
$x .= "$item\n$descr";
}
#$r->log->debug('My::Access::handler -- ' . join '/',grep
*{$_}{CODE},sort keys %My::Access::);
$r->log->debug("My::Access::handler -- \n$x");
}
if ( &needs_login($r) ) {
if ( &logging_in($r) ) {
# currently trying to log in (user/password supplied)
$r->log->debug('My::Access::handler logging in
(PerlHandler=>checkUser())');
my $h = $r->get_handlers( 'PerlHandler' );
unshift @{$h},\&checkUser ; # do &checkUser first
$r->set_handlers( PerlHandler => $h );
} else {
# no ticket, no username -- so ask for login
$r->log->debug('My::Access::handler needs login
(PerlHandler=>ask_login())');
$r->set_handlers( PerlHandler => [ \&ask_login ] );
}
}
return OK;
}
sub logging_in { #exists, but not as code?
...
}
sub needs_login {#exists, but not as code?
...
}
sub ask_login { #exists, but not as code?
...
}
sub make_login {# doesn't exist at all???
...
}
sub checkUser { #exists, but not as code?
...
}
sub make_welcome { # doesn't exist at all???
...
}
sub need_cookies { # doesn't exist at all???
...
}
1;
__END__
###
and here's the resulting log output, which gives my mind a
temporal inversion tachyon matrix pulse*:
###
[Thu May 3 00:09:04 2001] [notice] Apache/1.3.9 configured -- resuming normal
operations
[Thu May 3 00:09:04 2001] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu May 3 00:09:05 2001] [debug] /usr/local/lib/site_perl/My/Access.pm(52): [client
208.33.90.85] My::Access::handler --
BEGIN
SCALAR
OK
SCALAR
CODE
SERVER_ERROR
SCALAR
CODE
ask_login
SCALAR
checkUser
SCALAR
handler
SCALAR
CODE
logging_in
SCALAR
needs_login
SCALAR
[Thu May 3 00:09:05 2001] [error] Undefined subroutine &My::Access::needs_login
called at /usr/local/lib/site_perl/My/Access.pm line 55.
where's make_login? make_welcome? need_cookies? hmm? aaugh!
if it was a non-terminated string or something of that nature 1)
the perl tokenizer would object and 2) it would then be "all are
screwy from line X on downward" which ain't the case (checkUser
seems to show up on the radar, and it comes after make_login,
which is nowhere to be seen).
###
*star trek speak for "i have no *#$! idea what's happening here."
any wild-ass guesses would be appreciated. (do i win a prize for
the most difficulty with a simple situation? or at least an
honorable mention for most belligerent refusal to move on and get
a life?)
###
short version--
WTF?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
PerlAccessHandler via set_handlers()?
thanks one and all for the pointers on cookies. i probably grok
738% more than i did, but i have a feeling it's still only 13% of
the pie. or in this case, cookie...
so how's this PerlAccessHandler, for twisted logic? hole-punching
and pitfall-warning equally welcome:
#httpd.conf
PerlAccessHandler My::TrollUnderTheBridge
PerlHandler Something::OrOther
#perl
package My::TrollUnderTheBridge;
sub handler {
my $r = shift;
if ( &logging_in($r) ) {
my $h = $r->get_handlers( 'PerlHandler' );
unshift @{$h},\&checkUser ; # do &checkUser first
$r->set_handlers( PerlHandler => $h );
} elsif ( &needs_login($r) ) {
$r->set_handlers( PerlHandler => [ \&login ] );
# return AUTH_REQUIRED; or not ?
}
return OK;
}
sub checkUser {
my $r = shift;
if ( &bad_passwd( $r ) ) {
# generate html for username/password login screen, again
&login( $r );
# we handled it, other handlers won't be called (right?)
return OK;
} else {
$r->headers_out->add( 'Set-Cookie' => &make_ticket( $r ) );
# let normal handler do its thing
return DECLINED;
}
}
so i can keep the same url for all three stages, with no need for
preliminary cookies:
3. valid ticket -> show web pages
else
2. validate user/pass -> make ticket & show pages
else
1. login -> get user/pass
is this sound? or am i fuxnored?
--
but then from within &login() i'd like to be able to abort, like
so--
Re: glimmer of hope -- cookies: www.host.tld vs host.tld
On Wed, May 02, 2001 at 07:28:05AM -0400, darren chamberlain wrote: > will trillich ([EMAIL PROTECTED]) said something to this effect on 05/02/2001: > > Cookies are restricted to certain domains, for security reasons. > > (Why have a microsoft.com cookie sent to debian.org, right?) > > So all cookies need > > > > domain=box.subnet.intralan.organization.tld > > *snip* > > A similar thread happened a while ago (see, e.g., > >[EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/blixnortix/[EMAIL PROTECTED]); > Rusty Foster (of kuro5hin.org fame) explained his solution pretty well > here: > [EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/blixnortix/[EMAIL PROTECTED] here's the solution rusty posted: NameVirtualHost 216.181.35.174 # IP of www.kuro5hin.org # Redirect all hostless requests to www VHost ServerName kuro5hin.org Redirect permanent / http://www.kuro5hin.org/ # Proper URI for www.kuro5hin.org ServerName www.kuro5hin.org ...etc... how is that different from UseCanonicalName on -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
glimmer of hope -- cookies: www.host.tld vs host.tld
Aha. I found a chink. I still only have one brick in the wall, but now it seems like i may have a clue as to why the other bricks have been sitting there, giggling. to wit: Cookies are restricted to certain domains, for security reasons. (Why have a microsoft.com cookie sent to debian.org, right?) So all cookies need domain=box.subnet.intralan.organization.tld Or at the very least, two segments thereof: domain=.org.tld Which would be sent to any of these hosts: www.org.tld some.obscure.server.org.tld even.here.org.tld BUT NOT TO ord.tlg Thank you very four-borking-days-lost-forever much. So, patient gurus laughing-up-your-sleeves, who've known this from the beginning and have only been waiting for grashopper to come to the epiphany on his own, would you mind sharing with us lesser folk... HOW to have cookies work for bare-domain hosts such as this.org something.net my.tld to operate as aliases for more specific-style sites such as www.this.org www.something.net a.very.deep.and.remote.server.my.tld ? Please? at least i'm off the russian roulette kick. for now. -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: modify Server header via a handler
On Tue, May 01, 2001 at 12:10:34PM -0700, Randal L. Schwartz wrote: > > "newsreader" == newsreader <[EMAIL PROTECTED]> writes: > > newsreader> randal s. posted a way to do that > newsreader> sometime back. search for it in > newsreader> the archive. his stonehenge > newsreader> website apparently uses the same trick. > > If he's already doing it in the fixup phase, that's where I'm doing it > too, so that's probably not going to work. is it actually possible via perl? according to doug at http://www.geocrawler.com/archives/3/182/1997/6/0/1014229/ we shouldn't get our hopes up. -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAccessHandler -- struggling and drowning
On Tue, May 01, 2001 at 01:39:13PM -0500, will trillich wrote:
> On Tue, May 01, 2001 at 01:58:56PM -0400, Chris Strom wrote:
> > Even during a redirect. The following works for me (in a PerlInitHandler
> > NOT a PerlAccessHandler) with lynx (2.7) just fine.
> >
> > $r->err_headers_out->add('Location' => $dest);
> > $r->err_headers_out->add('Set-Cookie' => $cookie);
> >
> > $log->debug("Authentication successful. Redirecting to $dest");
> > return REDIRECT;
>
> okay, i'll try that, too. expectations low, from experience. :/
it's doing what it's supposed to do, i think.
guess what -- new speed bump. (color me surprised.)
now when lynx or netscape (but not konqueror) get validated, and
the server tries to redirect the browser back to the original
URL, the browsers seem to have cached the /login page as if it
were the /protected page.
so i'm trying
Pragma: no-cache
to no effect. anybody got any other ideas?
--
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAccessHandler -- struggling and drowning
On Tue, May 01, 2001 at 02:49:05PM -0400, Chris Strom wrote: > > http://www.no-way-in-hell-bubba.com/login/";> > > should be: > > http://www.no-way-in-hell-bubba.com/login/";> tolja my understanding was questionable. that helped that part, at least... much thanks! so now i feel like i've got one brick done, only forty-nine thousand, nine hundred ninety-nine to go. (union break time.) -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAccessHandler -- struggling and drowning
On Tue, May 01, 2001 at 01:58:56PM -0400, Chris Strom wrote:
> > > I can't say as I've had any problems using
> > > err_headers_out->add("Set-Cookie") with any browsers. I'm
> > > surprised to hear that you've had problems with it.
> >
> > even DURING a redirect? i seem to have hit a chord here, as
> > i'm getting lots of "me too" in my mailbox.
>
> Even during a redirect. The following works for me (in a PerlInitHandler
> NOT a PerlAccessHandler) with lynx (2.7) just fine.
>
> $r->err_headers_out->add('Location' => $dest);
> $r->err_headers_out->add('Set-Cookie' => $cookie);
>
> $log->debug("Authentication successful. Redirecting to $dest");
> return REDIRECT;
okay, i'll try that, too. expectations low, from experience. :/
> > something else i'm trying now is
> >
> > $r->set_handlers(PerlHandler => undef);
> > $r->push_handlers( PerlHandler => sub { ...print " > http-equiv...
>
> This ought to work and is a little more conceptually clean that what you
> were trying to accomplish with redirects and printing content in the
> PerlAccessHandler. Still, my gut feeling is that it's better to move the
> handler up the chain to a PerlInitHandler and do simple redirects there.
> Obviously it's preferable to perform access checks in PerlAccessHandlers,
> but sometimes you do need to set a cookie when doing redirects.
hmm. implying that cookie-setting gets borked in accesshandlers?
(mine sure do.)
> > but THIS for some reason redirects the browser back to itself,
> > instead of to the login area. the protected area is "/protected"
> > and the login area is "/login" so the http-equiv tag looks like
> > http://www.fricking-site.com/login";>
> but it cycles back to www.cannot-get-in.com/protected instead... !
>
> Are you setting HTTP headers?
% telnet no-way-in-hell-bubba.com 80
Trying ##.##.##.##...
Connected to no-way-in-hell-bubba.com.
Escape character is '^]'.
GET /protected HTTP/1.1
Host: no-way-in-hell-bubba.com
i ask for /protected on lunacy-for-lunch.com server, and get
HTTP/1.1 200 OK
Date: Tue, 01 May 2001 18:33:43 GMT
Server: Apache/1.3.9
Set-Cookie: request_uri=http%3A%2F%2Fno-way-in-hell-bubba.com%2Fprotected;
domain=.no-way-in-hell-bubba.com; path=/
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
148
http://www.no-way-in-hell-bubba.com/login/";>
Not logged in
Gotta log in, first
You're being redirected to http://www.no-way-in-hell-bubba.com/login";>http://www.no-way-in-hell-bubba.com/login
in just a moment.
Please stand by...
from my understanding, which gets shakier by the minute, the
headers and http-equiv are all correct. but lynx and netscape
both bounce like hell right back to /protected ad nauseum.
as if the meta tag was
http://yada-yada.com/protected";>
which it's not.
next i'll be taking up russian roulette. (i'll leave one chamber
empty, for sport.)
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAccessHandler -- struggling and drowning
Chris Strom wrote:
>
> > -Original Message-
> > From: will trillich [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 30, 2001 9:44 PM
> > To: [EMAIL PROTECTED]
> > Subject: PerlAccessHandler -- struggling and drowning
> > this is a PerlAccessHandler, which should check for the existence
> > of a cookie in the incoming headers, and if not there (or
> > expired) it should redirect the browser to a login area that
> > takes name/password pair, and if valid, would then return the
> > browser to the original URL. to do that, as we issue the
> > 'redirect to the login area' we set a cookie containing the URL
> > to return to.
> I can't say as I've had any problems using
> err_headers_out->add("Set-Cookie") with any browsers. I'm surprised to hear
> that you've had problems with it.
even DURING a redirect? i seem to have hit a chord here, as
i'm getting lots of "me too" in my mailbox.
> You might simply try giving up the use of
> a cookie for this, and encode the return URL in a query string instead.
> This is guaranteed to work regardless of browser, but you'll have to pass
> this information between pages (a reasonable trade off for choosing to
> support silly browsers, I suppose).
something else i'm trying now is
$r->set_handlers(PerlHandler => undef);
$r->push_handlers( PerlHandler => sub { ...print "http://www.fricking-site.com/login";>
but it cycles back to www.cannot-get-in.com/protected instead... !
this is bizarre enough i'm considering joining a monastery. at least
there, it's quiet.
--
mailto:[EMAIL PROTECTED]
http://www.dontUthink.com/
PerlAccessHandler -- struggling and drowning
Eeyore here, again, less happy than ever. S.O.S.
okay. i try to use the Ticket*.pm modules from the book
(chapter 6) verbatim and they work well for well-behaved
browsers.
to widen the workability (i.e. to make it functional for
badly-mannered browsers*) i'm trying some workarounds.
this is a PerlAccessHandler, which should check for the existence
of a cookie in the incoming headers, and if not there (or
expired) it should redirect the browser to a login area that
takes name/password pair, and if valid, would then return the
browser to the original URL. to do that, as we issue the
'redirect to the login area' we set a cookie containing the URL
to return to.
problem: some browsers see 'redirect' and ignore all other
headers, so the cookies aren't set. when the browser arrives at
the login area, there's no cookie to send there, to formulate
a return-to address from.
man CGI says 'we don't do http-equiv "meta" headers because you
can do those in header_out instead'. what's the politically
correct way to do this?
this also doesn't work (PerlAccessHandler)-- what would need to
be bent to make this function properly?
my $ticketTool = Apache::TicketTool->new($r);
#...
my $cookie = $ticketTool->make_return_address($r);
# (so we can get back to where user wanted to be)
my $login_uri = $r->dir_config("TicketLogin");
# instead of book's "ErrorDocument 403" example
use CGI '-autoload';
# note: PerlAccessHandler
print
header(-refresh => "1; URL=$login_uri", -cookie => $cookie),
start_html(-title => 'Redirecting to login', -bgcolor => 'white'),
h1('Please log in'),
p("You're being redirected to ",
a({-href=>$login_uri},$login_uri),
" in just a moment."),
h2("Please stand by..."),
end_html();
# return WHAT?
* note that the manners-ability of the browsers, being the
problem, is something i'm accepting on faith. if there's
another explanation (with a workaround that i might have a
chance at understanding) i'd love to hear it.
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: forbidden vs. cookie
On Mon, Apr 30, 2001 at 07:54:24PM -0400, Robert Landrum wrote:
> >On Mon, Apr 30, 2001 at 03:46:03PM -0400, Geoffrey Young wrote:
> >> > From: will trillich [mailto:[EMAIL PROTECTED]]
> >> > Sent: Monday, April 30, 2001 3:31 PM
> >> > To: [EMAIL PROTECTED]
> >> > Subject: forbidden vs. cookie
> >> [snip]
> >> > # this don't work so hot, neither:
> >> > $r->header_out(-cookie=>$cookie);
> >> > $r->header_out(-location=>$login_uri);
> >> > return REDIRECT;
> >> > # neither header is sent.
> >>
> >> you probably want $r->err_headers_out instead of $r->headers_out
> >
> >example on p. 125 doesn't -- but since success is zero for me
> >their way, i also tried your method, this way for thoroughness:
> >
> > # called as a "PerlAccessHandler", don't forget--
> > $r->header_out(Cookie=>$cookie);
> > $r->err_header_out(Cookie=>$cookie);
>
> Shouldn't these be
>
> $r->header_out('Set-Cookie'=>$cookie);
> $r->err_header_out('Set-Cookie'=>$cookie);
yep. i caught that right after i posted (as usual).
> > $r->header_out(Location=>$login_uri);
> > $r->err_header_out(Location=>$login_uri);
> > return REDIRECT;
so that part works -- meaning, the Set-Cookie header is sent, and
so is the Location redirector.
linux lynx ignores set-cookie in this case.
mac netscape does too.
g*ddamb*stardfu*kers, is all i'd like to add on that subject, at
the moment. (ask me in a minute, and i'll be glad to repeat it.)
so i'll fall back to
http://stupid-frogging-browser-compatibility-garbage/crapola.html";>
and try that *(&%^(*)($@#*((* method instead.
(are we having fun yet? some of us sure aren't! grr...)
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: forbidden vs. cookie
On Mon, Apr 30, 2001 at 03:46:03PM -0400, Geoffrey Young wrote: > > From: will trillich [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 30, 2001 3:31 PM > > To: [EMAIL PROTECTED] > > Subject: forbidden vs. cookie > [snip] > > # this don't work so hot, neither: > > $r->header_out(-cookie=>$cookie); > > $r->header_out(-location=>$login_uri); > > return REDIRECT; > > # neither header is sent. > > you probably want $r->err_headers_out instead of $r->headers_out example on p. 125 doesn't -- but since success is zero for me their way, i also tried your method, this way for thoroughness: # called as a "PerlAccessHandler", don't forget-- $r->header_out(Cookie=>$cookie); $r->err_header_out(Cookie=>$cookie); $r->header_out(Location=>$login_uri); $r->err_header_out(Location=>$login_uri); return REDIRECT; wouldn't you think that would do the trick? i sure did... Trying ##.##.##.## Connected to i-think-this-may-never-work-for-me.com. Escape character is '^]'. GET /secured HTTP/1.1 HTTP/1.1 302 Found Date: Mon, 30 Apr 2001 23:27:46 GMT Server: Apache/1.3.9 Location: http://www.i-think-this-may-never-work-for-me.com/login Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 302 Found Found The document has moved http://www.i-think-this-may-never-work-for-me.com/login";>here. the Location: header made it through, but the set-cookie: header got lost in the blast furnace somewhere. objective: return "set-cookie:" header while redirecting the largest number of browsers possible, getting around incompatibility problems with various browser implementations on varying platforms. any more rough nudges anybody would care to impinge? -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: forbidden vs. cookie
On Mon, Apr 30, 2001 at 03:46:17PM -0400, Ken Y. Clark wrote:
> Here is some code I've used in the past in a mod_perl app to
> set a cookie and do a redirect at the same time. I believe it
> works for most browsers -- or at least this code has been
> working for over a year and I haven't heard too many complaints
> about this piece (that I can think of).
>
> my $cookie = Apache::Cookie->new($apr,
> -name=> 'foo',
> -value => 'bar',
> -expires => '+30m',
> -domain => '.domain.com',
> -path=> '/',
> );
> $cookie->bake;
>
> $apr->method_number(M_GET);
> $apr->method('GET');
> $apr->headers_in->unset('Content-length');
> $apr->headers_out->add('Location' => '/foo');
> $apr->status(REDIRECT);
> $apr->send_http_header;
> return OK;
i presume $apr is as in "sub handler { my $apr = shift; ... " ?
and is this in PerlAuthhandler?
after seeing the 'expires' dilemma brought about by poorly
configured client system clocks, what advice should we follow?
(what's the Official Party Line on expiring cookies?)
--
[EMAIL PROTECTED]
forbidden vs. cookie
i could really use some dumbed-down tips on setting cookies
during a redirect. boy, this is really getting to me.
using apache 1.3.9 on debian 2.2/potato
in trying to implement the concept of the Apache::Ticket*.pm
modules from the Apache Modules (eagle) book in chapter 6
(on pages 304+) i'm running into browser compatibility problems.
SOME browsers (differs among platforms, too) see the forbidden or
redirect codes and take action immediately, ignoring any
set-cookie headers that are also sent.
as a workaround, i was trying to change TicketAccess.pm to
# the munged version trying to accomodate rude browsers:
package Apache::TicketAccess;
use strict;
use Apache::Constants qw(OK FORBIDDEN REDIRECT);
use Apache::TicketTool ();
sub handler {
my $r = shift;
my $ticketTool = 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);
#the original code that works for SOME browsers:
# $r->err_headers_out->add('Set-Cookie' => $cookie);
# return FORBIDDEN;
my $login_uri = $r->dir_config("TicketLogin");
# as AccessHandler, this was very much a bad idea:
# use CGI '-autoload';
# print
# header(-refresh => "1; URL=$login_uri", -cookie =>
$cookie),
# start_html(-title => 'Redirecting to login', -bgcolor
=> 'white'),
# h1('Gotta log in, first'),
# p("You're being redirected to ",
# a({-href=>$login_uri},$login_uri),
# " in just a moment."),
# h2("Please stand by..."),
# end_html();
# return OK;
# it does manage to redirect the browser but there's lots
# of duplicated headers and garbage (plus just hitting the
# BACK button bypassed the need to log in)
# this don't work so not, neither:
$r->header_out(-cookie=>$cookie);
$r->header_out(-location=>$login_uri);
return REDIRECT;
# neither header is sent.
}
return OK;
}
1;
__END__
i've spent hours flipping back and from from the index to the
text, slapping postit notes on every other page, scanning
Apache::*.pm source code -- and it's still not sinking in... a
little help would be appreciated!
AAUGH!
--
[EMAIL PROTECTED]
Re: cookies work for some browsers, not for others... ?
On Sun, Apr 29, 2001 at 12:21:33AM +0200, Robin Berjon wrote:
> At 17:17 28/04/2001 -0500, will trillich wrote:
> >so i guess what you're saying is, some browsers look for
> >a "redirect:" header and then charge off to the new location
> >without handling any "set-cookie:" headers in the meantime?
>
> Precisely. And some also don't report the cookie before the second page
> after the redirect (presumably because they consider it to be the same
> request). I think that behaviour only happens with permanent redirects though.
>
> One thing that helps (often, not always) is to make sure that your
> Set-Cookie header is sent before the Location header of the redirect.
here's the code, direct from the modperl book, and downloaded in
person from modperl.com:
package Apache::TicketAccess;
use strict;
use Apache::Constants qw(:common);
use Apache::TicketTool ();
sub handler {
my $r = shift;
my $ticketTool = 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;
}
return OK;
}
1;
__END__
i suppose i'd need to change
return FORBIDDEN;
to
print htmlheaders-including-meta-refresh, brief-html-stuff;
return OK;
right?
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: cookies work for some browsers, not for others... ?
On Sat, Apr 28, 2001 at 12:54:17PM -0700, Jim Winstead wrote: > in general, your problem with some browsers that otherwise support > cookies may be with issuing redirects and cookies on the same request, > which has been known to trip up some browsers. the easy workaround is > to use a refresh to do the redirection. pooh. i'll look into that. hmm. they all do the redirect properly, but when they arrive at the redirected url, they don't seem to have (or at least report) the cookies they've been given. so i guess what you're saying is, some browsers look for a "redirect:" header and then charge off to the new location without handling any "set-cookie:" headers in the meantime? > fmt: w70: No such file or directory hmm? -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
cookies work for some browsers, not for others... ?
i've been tinkering with the modperl book examples for Apache::Ticket*.pm (as described p305-322)... it works for linux/konqueror linux/netscape win/explorer it doesn't work for linux/lynx mac/netscape the ones that do work get to the login page with two textfields (username and password) with a login button; those that don't work get a "your browser doesn't accept cookies" page. where can i find some pointers on the differences between various browsers' adherence to standards, and hints on workarounds? (or, is this something else i've stumbled into?) -- here's a telnet trace of the situation, so apparently the program logic is working in all instances; but some browsers just won't play nice-- $ telnet sample-from-modperl-book.com 80 Trying ##.##.##.##... Connected to sample-from-modperl-book.com. Escape character is '^]'. GET /try HTTP/1.1 Host: sample-from-modperl-book.com HTTP/1.1 302 Found Date: Sat, 28 Apr 2001 19:26:48 GMT Server: Apache/1.3.9 Set-Cookie: request_uri=http%3A%2F%2Fsample-from-modperl-book.com%2Ftry%3F; domain=.sample-from-modperl-book.com; path=/ Location: http://www.sample-from-modperl-book.com/login Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 cf 302 Found Found The document has moved http://www.sample-from-modperl-book.com/login";>here. 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that "cf" that preceeds Log In Please Log In Name Password http://sample-from-modperl-book.com/try?";>Note: You must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with "294" in front, and "0" again taking up the rear. what's up with that? ??? -- don't visit this page. it's bad for you. take my expert word for it. http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: PerlAuthenHandler -- doesn't get there...? SOLVED
Stas Bekman replied:
> Argh, I wish I could always test every addition I have in the guide, some
> code goes untested as it was posted to the mod_perl or contributed by
> someone else. Then people come and use it, if something is wrong they send
> me a patch I fix it. I guess this is a similar scenario -- I admit that
> this code wasn't tested by me. If you find the problem and solve it,
> please send me the patch, so everybody could benefit from it.
>
> As for hints you want to read the Eagle book, I try hard not to duplicate
> information in the book, but sometimes I do. The book covers extensively
> the Authentication handler writing. You should start from the Basic one
> that works for you and then move on and add the extra, more complicated
> logic inside.
>
> I'm looking forward for the patch :) Thanks a lot!
hmm! "hey, i'm lost in the sears tower. can anybody tell me
how to turn the lights on?" "whoops. maybe if you build your
own skyscraper you can get back with us on that..." :)
so here's what i've stumbled into, in the dark--
i'm using apache 1.3.9 on debian/gnu linux 2.2:
ONE--
from http://perl.apache.org/current/htdocs/manual/mod/mod_perl.html
PerlModule directive
Description: List of Perl modules
Syntax: PerlModule Arg1 x n (ITERATE)
PerlSyntax: push @PerlModule, $arg1
Context: Allowed in *.conf anywhere and in .htaccess
Override: Any other than None
Status: Extension
Module: mod_perl
yet when i put 'PerlModule Serensoft::Auth' into
the .htaccess file i consistently got
[notice] child pid 30127 exit signal Segmentation fault (11)
moving it back into the /etc/apache/httpd.conf file,
all is sparkly again.
TWO--
if i modify the .htaccess file or the Auth.pm file, it's
USUALLY silently ignored until i do
'apachectl graceful'
although sometimes .htaccess updates are activated.
i presume that even having five or ten child apaches running
around loose, it's the one that's dealing with the request that
checks for updates to required modules & settings files...
should i hafta 'graceful' just to update Auth.pm or .htaccess?
THREE--
according to /usr/doc/apache/manual/mod/core.html, the
AuthName and AuthType are allowed in .htaccess and
directory sections only, NOT location sections; this
could be a documentation oversight, i reckon.
FOUR--
i'm now reasonably certain (90% or so) that the missing
ingredients were basically indicated by Eric Cholet when he said
> maybe you need "Order deny, allow" to trigger authentication
seems that i also needed the companion
deny from all
as well (he probably thought i knew enough to presume that,
but alas, i only now begin to see...).
===
SO -- Stas, here's a coupla extra tweaks i think you should
make so that cut/paste newbies (unlike me, of course) will
have an easier time with this particular example on the next
iteration:
My/Auth.pm--
[snip]
sub authen_handler {
[snip]
my $reason = authen_dbi ($r, $user, $sent_pw, $level);
#
# '$level' looks like an artifact from the
# original code that isn't part of this example.
#
[snip]
sub authen_dbi{
my ($r, $user, $sent_pw, $level) = @_;
#
# $level, again. omit.
#
# validate username/passwd
return 0 if (*PASSED*)
#
# i'd leave this as is; if you change it to a real perl
# expression such as /PASSED/ some newbies will sail right
# on by, wondering why they'll never authenticate properly
# (i'd be one of them).
#
return "Failed for X reason";
}
1;
#
# add the 'require'-friendly 'non-zero final statement'
#
httpd.conf or .htaccess (PerlModule hasta be in httpd.conf,
from my experience)--
PerlAccessHandler My::Auth::access_handler
PerlSetVar Intranet "10.10.10.1 => userA, 10.10.10.2 => userB"
PerlAuthenHandler My::Auth::authen_handler
AuthName realm
AuthType Basic
Require valid-user
order deny,allow
deny from all
#
# add 'order/deny', and we're done (as far as i can tell)
#
and there you have it. i think.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Their is five errers in this sentance.
Re: PerlAuthenHandler -- doesn't get there...?
thanks for your posts, guys!
Eric Cholet replied:
> > i copied the sample code from 'illustrated security scenarios'
> > at http://perl.apache.org/guide/security.html nearly verbatim,
> > (cut & paste + munge) changed '(*PASSED*)' to a simple test
> > (moot, at this point) and inserted a few $r->warn("") for tracing
> > and debugging purposes.
> >
> > access_handler() works fine. all its $r->warn output shows up
> > in the logfile as it should.
> >
> > BUT i never see any incursion into the authen_handler() AT ALL!
>
> maybe you need "Order deny, allow" to trigger authentication
Steve van der Burg replied:
> After looking at my own configuration for
> Apache::AuthCookie, and snooping in the Apache source a
> bit, I think that your "AuthType Basic" needs to be
> changed to "AuthType Serensoft::Auth".
tried both... alas, still no entry into authen_handler.
it's never executed at all.
(Steve--docs for most of the standard auth modules [see your
local http://localhost/doc/apache/manual/mod/] which seem
to indicate 'AuthType Basic' not 'AuthType Mod::Path'...?)
if Stas can get it to work using the framework on the guide page,
what've i got missing? (can anybody confirm that it can/does
run as expected?)
what modules are required for this simple authenticator to work?
there's gotta be something i'm missing. Doesn't look like
'AuthUserFile' or the like, would come into play, does it?
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Their is five errers in this sentance.
PerlAuthenHandler -- doesn't get there...?
i canna get the PerlAuthenHandler to do ANYTHING. first
line of code after $r = shift is $r->warn() but nothing
shows up in the log. aaugh!
i copied the sample code from 'illustrated security scenarios'
at http://perl.apache.org/guide/security.html nearly verbatim,
(cut & paste + munge) changed '(*PASSED*)' to a simple test
(moot, at this point) and inserted a few $r->warn("") for tracing
and debugging purposes.
access_handler() works fine. all its $r->warn output shows up
in the logfile as it should.
BUT i never see any incursion into the authen_handler() AT ALL!
[my main site is serensoft.com; the virtual site is dontUthink.com
and the url i'm trying to test is dontUthink.com/auth ... it lets
me in, every time, without asking for any userid:password.]
httpd.conf:
PerlModule Serensoft::Auth
PerlAccessHandler Serensoft::Auth::access_handler
PerlSetVar Intranet "this => that"
PerlAuthenHandler Serensoft::Auth::authen_handler
AuthName "dontUthink subscriber"
AuthType Basic
Require valid-user
Serensoft/Auth.pm:
Package Serensoft::Auth;
use strict;
use Apache::Constants qw(:common);
[snip]
sub authen_handler {
my $r = shift;
$r->warn('authen_handler'); # <== NEVER gets here!!!
# get user's authentication credentials
my ($res, $sent_pw) = $r->get_basic_auth_pw;
return $res if $res != OK;
my $user = $r->connection->user;
# authenticate through DBI
my $reason = authen_dbi ($r, $user, $sent_pw); # $level? eh?
if ($reason) {
$r->note_basic_auth_failure;
$r->log_reason ($reason, $r->uri);
return AUTH_REQUIRED;
}
return OK;
}
i even tried adding
$r->set_handlers(PerlAuthenHandler => [\&authen_handler]);
right at the end of access_handler() (before returning OK)
but alas, to no avail.
what obvious dial have i forgotten to frob?
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Their is five errers in this sentance.
Apache::Constants::NOT_FOUND() -> undefined?
this is bound to be simple, so of course i'm at a loss to find it... % perl -MApache::Constants -e 'print NOT_FOUND' Undefined subroutine &Apache::Constants::NOT_FOUND called at -e line 1. i also try it via #!/usr/bin/perl use Apache::Constants qw(:standard); print NOT_FOUND; with identical results (i.e. the requested constants are not defined). what am i not seeing? -- % perl -v This is perl, version 5.005_03 built for i386-linux [snip] % perl -MApache::Constants -e 'print join "\n",values %INC' /usr/lib/perl5/5.005/i386-linux/Apache/Constants.pm /usr/lib/perl5/5.005/AutoLoader.pm /usr/lib/perl5/5.005/Exporter.pm /usr/lib/perl5/5.005/strict.pm /usr/lib/perl5/5.005/i386-linux/Apache/Constants/Exports.pm /usr/lib/perl5/5.005/i386-linux/mod_perl.pm /usr/lib/perl5/5.005/i386-linux/DynaLoader.pm /usr/lib/perl5/5.005/vars.pm % uname -a Linux server.serensoft.com 2.0.36 #2 Sun Feb 21 15:55:27 EST 1999 i586 unknown and, not that it matters in this instance... % apache -v Server version: Apache/1.3.9 (Unix) Debian/GNU Server built: Apr 29 2000 10:48:16 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Their is five errers in this sentance.
Re: Script that stays on the same page
Pierre-Yves BONNETAIN wrote: > >Hello, > >For my server, I need to write some script that will be 'regularly' > triggered (GET or POST), but that will NOT send the user to another page. The > user must stay on the same page he is, without ANY html being exchanged as > a result of the script. >This will be used to change parameters on the user's session, but since > those params will not affect the page the user is currently looking at, there > is no need to send HTML back. >So, 1/ can it be done ? 2/ How ? www.macconnection.com or www.pcconnection.com do a nice job of this. see any of their 'smart selectors'... every time you select a menu option, the number of items 'found' by the /server/ scripts, based on the users' new parameters, pop up into a text box. very slick. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Their is five errers in this sentance.
perlSendHeader On/Off: the difference!
perlSendHeader On / Off -- what's the real difference?
i finally figured it out, after seeing many 'server errors'
on one hand, and http headers cluttering up the html output
to the browser on the other...
i have a perl script
test.npl
and a symbolic link to it
`ln -s test.npl test.pl`
so that the same code will be called whether it's
*.pl or *.npl...
and in httpd.conf,
Options +ExecCGI
SetHandler perl-script
PerlSendHeader On
PerlHandler Apache::PerlRun
Options +ExecCGI
SetHandler perl-script
PerlSendHeader Off
PerlHandler Apache::PerlRun
so any script named *.pl runs with perlSendHeader ON;
any script named *.npl runs with perlSendHeader OFF.
here's the relevant code from the top of the script:
my $eol = "\015\012";
my $mod = scalar localtime( $seen{$path} ||= (stat $path)[9] );
my $span = 60*60*24;
print "HTTP/1.1 200 OK",$eol
if $0 =~ /\.npl$/ # if PERLSENDHEADER == OFF, say 'HTTP/...'
;
print "Content-Type: text/html",$eol,
"Last-Modified: ",$mod,$eol,
"Date: ",scalar(localtime),$eol,
"Expires: ",scalar(localtime(time+$span)),$eol,
$eol
;
print ""
and the script behaves identically, whether called
as *.npl or *.pl, with no server error (missing headers)
and no http clutter at the top of html output (extra
headers).
thus i conclude that (aside from the internals revealed at
http://perl.apache.org/faq/mod_perl_cgi.html#The_script_runs_but_the_headers_
) PERLSENDHEADER ON makes mod_perl generate the initial
'HTTP' intro, and that's that.
yes? no? do i win a prize?
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Their is five errers in this sentance.
