Re: load balancing on apache by IP CHAINING

[David Young]

Servlet chaining is what the Java web server will do, and it has nothing to
do with load balancing (that I can think of).

ipchains is the command to enable firewall/packet filter/packet masquerading
capability in linux. I would suppose that it can be used to round-robin
requests or something, but I don't know how to set that up.

> From: Medi Montaseri <[EMAIL PROTECTED]>
> Date: Sat, 15 Dec 2001 20:57:19 -0800 (PST)
> To: Anand R <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: load balancing on apache by IP CHAINING
> 
> 
> I'm confused'IP chainging' as the name says is at the IP (or Network)
> layer, what does that have to do with Apache or any HTTP server at the
> application level.
> 
> I think any such IP based load balancing technologies are inherently
> unaware of the total system issues and are simply making a jugdment based
> on the IP level or perhaps a specific protocol on top of IP to route the
> next packet (or next session). Having said that a Perl HTTP would/could
> benefit from it just as well...
> 
> On Sat, 15 Dec 2001, Anand R wrote:
> 
>> IP chaining can be done in Java Webserver,
>> How to do it in Apache Webserver.
>> 
>> Please let the Ring know this,
>> Thanks in advance,
>> Regards,
>> Anand 
>> - Original Message -
>> From: Derek Jones
>> To: Hemant Singh ; [EMAIL PROTECTED]
>> Cc: Derek G Jones
>> Sent: Friday, December 14, 2001 7:29 PM
>> Subject: RE: load balancing on apache
>> 
>> 
>> 
>> Hi all,
>> 
>> You can do load balancing using ipchains as well.
>> 
>> Can't remember the program name offhand, but if I have time
>> I'll look it up and let the list know.
>> 
>> Only works if your servers are Linux of course.
>> 
>> Kind regards
>> 
>> Derek.
>> --
>> Derek Jones  1051, Bollinger Road,
>> Tel:717 359 8817  Littlestown,
>> Mobile: 717 977 4556PA, 17340, USA
>> Email: [EMAIL PROTECTED]
>> AIM:   scunacc 
>> 
>> 
> 
> -- 
> -
> Medi Montaseri   [EMAIL PROTECTED]
> Unix Distributed Systems EngineerHTTP://www.CyberShell.com
> CyberShell Engineering
> -
> 
> 

Re: Doing Authorization using mod_perl from aprogrammersperspective

[David Young]

I would still say this is dangerous. There is no guarantee that the same
client will use the same IP and/or socket every time. Think about the
thousands of AOL users behind hundreds of proxies. There is no consistency.
Even with 10 users behind one NAT firewall I bet you'll have problems.

> From: Jon Robison <[EMAIL PROTECTED]>
> Date: Mon, 10 Dec 2001 18:06:00 -0500
> Cc: [EMAIL PROTECTED]
> Subject: Re: Doing Authorization using mod_perl from a programmersperspective
> 
> To insert a new comment on this old item:
> 
> What about sockets?  I am in the middle of trying to use $c =
> $r->connection and $c->remote_addr as part of the cookie name.  (So far
> I am having trouble with the fact that remote_addr returns packed info,
> and I am still searching for how to unpack it - if you know, tell me!).
> 
> It's not 'foolproof', but how many casual cookie stealers can force
> their browser to use a particular socket?
> 
> This little method would even allow me to open multiple windows into a
> secured area, each with a different username, etc. (Very usefull during
> user interface development, etc. where menus differ based on some
> criteria for users)
> 
> --Jon Robison
> 
> 
> David Young wrote:
>> 
>> fliptop wrote:
>>> Joe Breeden wrote:
>>>> 
>>>> How does this work in an environment with two (or more) computers with the
>>>> exact same configuration, and probably the same HTTP_USER_AGENT behind the
>>>> same proxy? How do you know that one user isn't using another users
>>>> session?
>>> 
>>> you don't.  the session hijacker still would need to know the real
>>> user's username, password, and HTTP_USER_AGENT configuration.
>> 
>> The session hijacker would not need to know the username and password. They
>> would only need to sniff the cookie from the network, and then send it from
>> a client identifying itself as the same User Agent.
>> 
>>> my point
>>> was that this solves the problem of using the ip address in the md5 hash
>>> when the client is behind a proxy server.
>> 
>> This does not solve the problem: IP address of users behind Proxy is not
>> unique. The User Agent is not unique either. Using User Agent solves
>> nothing, and is in fact far less secure, since the client can set the User
>> Agent header to be just about anything. At least the IP address has to be
>> correct (but not unique) if the client wants to get a response.
> 

Re: Problem with Apache::AuthCookie-3.00

[David Young]

Well, I didn't see any other replies to this... so I'll comment: I don't get
what you are saying here... Could you rephrase it and clarify if you are
talking about AuthTicket or AuthCookie?


> From: Steven Lembark <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Fri, 07 Dec 2001 01:34:57 -0600
> To: [EMAIL PROTECTED]
> Subject: Problem with Apache::AuthCookie-3.00
> 
> 
> Getting multiple HTTP replies returned to the client. They
> get a form and followig it an 'access denied' message from
> Apache.
> 
> The examples I've seen of login_form code use a simple print to
> get things on the screen (e.g., Apache::AuthTicket).
> I've tried this and various combinations of sending the headers
> and form with no luck.
> 
> Ideally Apache::AuthCookie should only require the login_form,
> authen_cred and authen_ses_key sub's to function with the
> addition of login_screen to use a location rather rather than
> #!-ed code for the login form.
> 
> Does anyone know of a simple, working example of deriving a
> class from Apache::AuthTicket or some specific documentation
> for a complete class? The code that comes with it is only
> useful for testing; the other modules include quit a bit of
> non-AuthCookie sub's that may have a bearing on how the
> form is handled. The login_form is taken from Apache::AuthTicket
> (basically just a header and static body).
> 
> My sub-class also overloads authentication to call login_form($r)
> rather than without arguments.
> 
> sub authen_cred( $$\@ ) { "foo" }
> 
> sub authen_ses_key( $$$ ) { "foo" }
> 
> sub login_form
> {
> my( $class, $request ) = @_;
> 
> $request->no_cache( 1 );
> $request->send_http_header( 'text/html' );
> $request->print( $form );
> 
> OK
> }
> 
> 
> 
> --
> Steven Lembark   2930 W. Palmer
> Workhorse Computing   Chicago, IL 60647
> +1 800 762 1582
> 

Re: delayed file uploads...

[David Young]

I'd say "no". Uploading the file is a function of the browser and not under
your control.

> From: "El Capitan" <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: Mon, 3 Dec 2001 15:29:08 -0800
> To: <[EMAIL PROTECTED]>
> Subject: delayed file uploads...
> 
> i have a simple question.  im not sure if there is a mod_perl directive or
> module for this but id like to perform this simple task:
> 
> two web pages run in sequence. the first page, id like a user to select
> several files from his/her machine for uploading to the server using the
> input type "file" tag.  when the user requests the next page, i DO NOT want
> the files to immediately transfer (many reasons for this, just a hard
> requirement).  rather, id like to store the names of the files into a cookie
> or save it on the server with apache::session.  this part I already have
> working, and am storing the file names into a tied hash using
> apache::session module.
> 
> then the user moves onto the second web page and populates more form fields
> with additional information.  upon submitting this second form, the files
> from the previous web page (names stored in the hash %session from
> apache::session) are then sent to the server.
> 
> im not sure whether or not this can be done, anyone have any clues?
> 
> 
> 
> Kirk
> 
> 

Re: How to create a browser popup window

[David Young]

This is not really a mod_perl question. Pop-up windows can only be created
using client-side scripting like Javascript. Your handler would need to
output the necessary Javascript to cause the pop, like:


url = "/pop/source.html";
name = "popwin";
h = 250;
w = 350;
var theWin = window.open(url, name, 'scrollbars=yes, resizable=yes,
toolbar=no, height='+h+', width='+w);
theWin.focus();


For more information on how that works, read Javascript docs:
http://developer.netscape.com/docs/manuals/?content=javascript.html



> From: "Domien Bakker" <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2001 15:30:45 +0100
> To: <[EMAIL PROTECTED]>
> Subject: How to create a browser popup window
> 
> Hello all,
> 
> Can anybody give me the "golden" tip of creating a popup browser window
> from my mod_perl handler? I want to fill in this popup window with
> results 
> generated within my handler.
> 
> Is there a module available from CPAN which can handle this?
> 
> Thanks in advance!
> 
> Met vriendelijke groet / With kind regards,
> Domien Bakker
> Application Developer
> 
> Application development
> Operations and Engineering
> ZeelandNet BV
> 
> Postbus 35
> 4493 ZG Kamperland
> The Netherlands
> tel. +31 (0)113 377733
> fax +31 (0)113 377784
> [EMAIL PROTECTED]
> http://ww.zeelandnet.nl/
> 
> 
> 
> 

Re: Doing Authorization using mod_perl from a programmersperspective

[David Young]

There seems to be some confusion over exactly what we're talking about...

Apache::Session may work fine for creating a unique session ID, however this
thread has really been about how to ensure that a session hasn't been
hijacked. People have been suggesting various bits of info they could get
from the client (IP, User Agent) and set in the cookie, thereby ensuring
that the cookie is coming back from the client to whom they sent it.

There isn't anything you can use that will work 100%. The only way you can
ensure that your cookies aren't being hijacked is to only send them over an
SSL connection.

> From: Jon Robison <[EMAIL PROTECTED]>
> Date: Mon, 19 Nov 2001 10:47:33 -0500
> To: "Randal L. Schwartz" <[EMAIL PROTECTED]>
> Cc: fliptop <[EMAIL PROTECTED]>, "Jonathan E. Paton"
> <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Doing Authorization using mod_perl from a programmers perspective
> 
> How about using an Apache::Sessions id instead of IP address?

Re: Cookie authentication

[David Young]

As I mentioned before, if you dissect what they do with cookies and when,
you'll find they maintain two levels of session tracking, one for
"non-sensitive" personalization uses and one for "sensitive" authentication
uses. The URL session ID is likely only the former, and not exposing
anything sensitive.

I haven't spent a lot time seeing what they do when I disable cookies, but I
do know that if I copy an URL (which contains my session ID) and send it to
a friend, when that friend clicks on it, Amazon redirects to a new URL with
a different session ID.


> From: Rob Nagler <[EMAIL PROTECTED]>
> Organization: bivio Software Artisans, Inc. 
> Date: Fri, 16 Nov 2001 15:22:02 -0700
> To: [EMAIL PROTECTED]
> Subject: RE: Cookie authentication
> 
>> If you happen to type in a URL, they can revive your
>> session from the cookie.  Pretty nifty trick.
> 
> This would seem to be a security hole to me.  URLs appear in the logs
> of the server as well as any proxy servers along the way.  If the URL
> contains reusuable auth info, anybody accessing any of the logs could
> gain access to customer accounts.

Re: Doing Authorization using mod_perl from a programmersperspective

[David Young]

Yes I remember reading about this some time ago. Of course I am short on
specifics, but IIRC those were some sort of signature put in by ISPs who
were bundling IE, and the id transmitted only configuration info but not
specific user details.

> From: Stephen Adkins <[EMAIL PROTECTED]>
> Date: Fri, 16 Nov 2001 12:13:48 -0500
> To: Joe Breeden <[EMAIL PROTECTED]>,[EMAIL PROTECTED]
> Subject: RE: Doing Authorization using mod_perl from a programmers perspective
>
> Mozilla/4.0 (compatible; MSIE 5.0; Windows
> 95)::ELNSB50::81100320025802f901780505000b
>
> This indicates to me that some vendors who distribute MSIE 5.0
> on their PC's include some sort of ID in the HTTP_USER_AGENT
> that the browser reports. (!?!) (privacy advocates beware!)

Re: Doing Authorization using mod_perl from a programmersperspective

[David Young]

fliptop wrote:
> Joe Breeden wrote:
>> 
>> How does this work in an environment with two (or more) computers with the
>> exact same configuration, and probably the same HTTP_USER_AGENT behind the
>> same proxy? How do you know that one user isn't using another users session?
> 
> you don't.  the session hijacker still would need to know the real
> user's username, password, and HTTP_USER_AGENT configuration.

The session hijacker would not need to know the username and password. They
would only need to sniff the cookie from the network, and then send it from
a client identifying itself as the same User Agent.

> my point
> was that this solves the problem of using the ip address in the md5 hash
> when the client is behind a proxy server.

This does not solve the problem: IP address of users behind Proxy is not
unique. The User Agent is not unique either. Using User Agent solves
nothing, and is in fact far less secure, since the client can set the User
Agent header to be just about anything. At least the IP address has to be
correct (but not unique) if the client wants to get a response.

Re: Cookie authentication

[David Young]

I don't think that really solves Joe's proposed problem. Joe wants to ensure
that the cookie is coming back from the client he sent it to. If you
generate a unique ID, someone can sniff the network, grab the cookie, and
send it as their own. The Eagle book does half-heartedly suggest IP address
as being a way to ensure the cookie's source, but that's not reliable in
these days of proxies and NAT.

The only answer, I think, is to only send the cookie over an SSL connection,
so that it can not be sniffed. Remember that there is an attribute you can
set on the cookie that tells the browser to only send the cookie over an SSL
connection.

Spend some time playing with Amazon and see how they handle cookies. They
appear to have cookies that get sent over every connection which they use to
personalize your web pages (not necessarily sensitive info). However, as
soon as you try to purchase something or go to a sensitive area, you are
asked to sign-in and sent a cookie over https.


> From: "Perrin Harkins" <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2001 18:40:03 -0500
> To: "Joe Breeden" <[EMAIL PROTECTED]>, "mod_perl List" <[EMAIL PROTECTED]>
> Subject: Re: Cookie authentication
> 
>> Excuse my question if it seems dumb I'm not 100% on NAT and
>> proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to
> be
>> user for the MAC. It also suggests to use the remote IP address as one of
>> those fields. 3 Compute the MAC via a MD5 hash and store in the clients
>> browser. 4 On subsequent visits recompute the MAC and verify it matches
> the
>> original stored MAC. How is this reliable in a situation where many
>> similarly configured computers are behind a NAT/Proxy and one of the users
>> try to steal someone else's session by getting their cookie/session_id
> info?
> 
> Don't use the IP address in the cookie, just generate a unique ID of your
> own.  I suggest using mod_unique_id.
> - Perrin
> 
> 

Re: http or https in URL?

[David Young]

This will not work all the time for all configurations. 80 is the default
port for http and 443 is the default port for https. However, just as you
may choose to run your http server on any port you wish, you may also choose
to run your https server on any port you wish.

> From: Rob Nagler <[EMAIL PROTECTED]>
> Organization: bivio Software Artisans, Inc. 
> Date: Tue, 6 Nov 2001 08:45:45 -0700
> To: [EMAIL PROTECTED]
> Subject: Re: http or https in URL?
> 
>> But how do I get the protocol, http or https.
> 
> You can check the port on $c->local_addr.  443 is https.
> 
> Rob
> 
> 
> 
> 
> 

[OT] Nimda, etc (was: New mod_perl hacker wannabe . . .)

[David Young]

FWIW, Apache::CodeRed seemed like a good idea for a while, and then Nimbda
showed up, and it was apparent no one was actually doing anything about the
infected machines. I got sick of the notifications and the junk in my error
log, so I resorted to this handler:

  
SetHandler perl-script
PerlHandler "sub { return OK; }"
  



> From: "John Michael" <[EMAIL PROTECTED]>
> Date: Sun, 28 Oct 2001 20:27:03 -0600
> To: <[EMAIL PROTECTED]>
> Subject: Re: New mod_perl hacker wannabe . . .
> 
> My server is constantly getting scanned by various hacking robots.  I will
> get hundreds of these a day or more sometimes.
> 
> [Sun Oct 28 18:51:00 2001] [error] [client 64.81.175.236] File does not
> exist: /home/usr1/digital/html/scripts/root.exe
> [Sun Oct 28 18:51:01 2001] [error] [client 64.81.175.236] File does not
> exist: /home/usr1/digital/html/MSADC/root.exe
> [Sun Oct 28 19:28:29 2001] [error] [client 64.81.41.2] File does not exist:
> /home/usr1/digital/html/scripts/root.exe

Re: namespace-troubles

[David Young]

Hey, it just so happens I was reading-up on the voluminous mod_perl
documentation out there, and it would appear I stumbled across the answer to
your problem:

http://perl.apache.org/dist/mod_perl_traps.html#Perl_Modules_and_Extensions

> From: Peter Pilsl <[EMAIL PROTECTED]>
> Date: Wed, 24 Oct 2001 00:48:44 +0200
> To: [EMAIL PROTECTED]
> Subject: namespace-troubles
> 
> I run into deep namespacetroubles I understand onyl vaguely and I cant
> workaround:
> 
> I have a script running under mod_perl that is called via two domains.
> 
> www1.domain.at/  
> www2.domain.at/sub/
> 
> both of the above addresses lead to the very same script (its the same
> file on the disk, not a copy). When I call the first adress all is
> working fine, but as soon as I call the second adress I get a
> server-error.  Restarting apache and I try the second first: running
> fine, but as soon as I call the first: server-error.
> 
> The log reveals:
> 
> Undefined subroutine &Apache::ROOTwww1_2domain_2eat::main called at
> /data/public/stage2/fetch.pl line 9.
> 
> or
> 
> Undefined subroutine
> &Apache::ROOTwww2_2edomain_2eat::editeinstieg::main called at
> /data/public/stage2/fetch.pl line 9.
> 
> my script is structured like that:
> fetch.pl:
> require fetch.lib.pl
> main();
> -
> 
> ---fetch.lib.pl:
> sub main{
> 
> do everthing here
> 
> }
> 1;
> 
> 
> As far I can see, the second call does not load the lib anymore, cause
> it was already loaded on the first call. Unfortunately it was loaded
> to a different namespace, so the script doesnt find it.
> 
> What can I do ? I need this different domains, cause the script-action
> depends on the calling domain.
> 
> The reason why I splitted in script/lib is a document at apache.org
> that recommends this to avoid a nested-sub-problem under mod_perl.
> 
> I wonder if providing the lib-file as module (use instead of require)
> would be a solution, but I guess not.  Can the above problem occure
> with modules too ? If two scripts call the same module, is it only
> loaded on the first call and the second script fails ??
> 
> thnx,
> peter
> 
> 
> -- 
> mag. peter pilsl
> 
> phone: +43 676 3574035
> fax  : +43 676 3546512
> email: [EMAIL PROTECTED]
> sms  : [EMAIL PROTECTED]
> 
> pgp-key available
> 

authcookie segmentation faults

[David Young]

I had users complaining of intermittent "document contains no data" errors
when logging in (using AuthCookie). I wrote a script to repeatedly POST to
the AuthCookie LOGIN method. I am finding that after 15,000 POSTs or so, I
start getting a lot of segfaults (child pid 12494 exit signal Segmentation
fault (11)). It then quiets down for another 15,000 requests or so, and then
segfaults some more.

The mod_perl guide mentioned some problems with php, so I got rid of all the
php modules. I also gather that my PerlFreshRestart setting won't matter
since mod_perl is a DSO (Apache/1.3.14 mod_perl/1.24).

Any tips how I can track this down?

Re: embedding perl code to html

[David Young]

http://perl.apache.org/features/tmpl-cmp.html

- Original Message -
From: "Mike V. Andreev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 11:28 AM
Subject: embedding perl code to html


>
> Hi!
>
> I have a tree of static html files and perl cgi-scripts. But sometimes I
> want to include some simple functionality in html-file. The best
> solution, I think, is including perl code to html file. I found
> several tools on the Net. The best i liked is Embperl
> (http://perl.apache.org/embperl/) & ePerl
> (http://www.engelschall.com/sw/eperl/) . Both of them have similar
> functionality. But before I make final choice i want to hear some
> comments about its speed, feature, reliability etc. Or may be someone
> know other tools? (I don't need very powerful thing -- main
> programming will be in perl scripts anyway, so there isn't necessity
> in some cool libraries and stuff )
>
> Thanks in advance . Best regards.
>
> -
> Mike Andreev
> Programmer
> SMIS Lab, Space Research Institute (Moscow, Russia).
http://smis.iki.rssi.ru
> [EMAIL PROTECTED]
> -
>
>
>

Re: AuthCookie access denied messages

[David Young]

Agreed, however I'd like to at least say "The username and/or password you
entered was not recognized".

> From: Ged Haywood <[EMAIL PROTECTED]>
> Date: Tue, 21 Aug 2001 00:36:33 +0100 (BST)
> To: David Young <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: AuthCookie access denied messages
> 
> It's generally considered a security hole to report things like
> "invalid user id" to a user who fails to get a login, because when he
> finally gets "invalid password" he knows he's got a valid user id...
> 
> 73,
> Ged.

AuthCookie access denied messages

[David Young]

Before I tackle this myself, has anyone added functionality to AuthCookie so
that it will report *why* a user is being asked to login? Currently, if a
user enters in a wrong username or password, they just get redirected back
to the login form with no explanation.

Thanks,
--David

Re: module to hit back at default.ida atack ?

[David Young]

From: Mark Maunder <[EMAIL PROTECTED]>
> Perhaps we should just keep a central database of where the attempts are
> coming from.
> We could even extend it to work like the RBL - connects are not allowed from
> IP's that have attempted the exploit

Would that really help anything? The traffic would still be reaching your
server and clogging up the net, the only difference is that you'd be
returning an access denied response rather than a 404.

What would really help is if all the ISPs out there put filters on their
routers to catch these requests as close to their source as possible.

[OT] Re: Module to catch (and warn about) Code Red

[David Young]

About 80% of the Code Red probes I get leave the message "Client sent
malformed header" in my error_log. Just curious if others are seeing this?

Re: detecting ssl

[David Young]

I agree with Vivek. With an URL in the format:

://:

The browser will use  to connect to  on . If you
don't specify , then the browser will pick the default  for
, but if the server is not serving the specified  on the
default , you won't get .

> From: Vivek Khera <[EMAIL PROTECTED]>
> Organization: Khera Communications, Inc., Rockville, MD
> Newsgroups: ml.apache.modperl
> Date: 11 Jul 2001 15:17:11 -0400
> To: [EMAIL PROTECTED]
> Subject: Re: detecting ssl
> 
>> "IG" == Issac Goldstand <[EMAIL PROTECTED]> writes:
> 
> IG> Not necessarily.  I could easily set up any virtualhost on port
> IG> 443 which will be accessable by https://nasty.servername/ but
> IG> will, in reality, not necessarily be over a secure connection.
> 
> I think you've never actually tried this.  You will not get the page
> because the client is expecting SSL and you're not providing it.  Try
> it.  Go ahead, try it.
> 
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D.Khera Communications, Inc.
> Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/
> 

Re: can not redirect on POST w/ CGI.pm

[David Young]

>From: "Rodney Broom" <[EMAIL PROTECTED]>
> From: David Young <[EMAIL PROTECTED]>
> DY> I've found that if I post to this PerlAccessHandler, I get no response:
> DY> $r->header_out(Location => "http://www.modperl.com/";);
> DY> return REDIRECT;
> 
> - Are you actually wanting your orriginally POSTed data to make it to the
> redirected location?
> - Do you actually need CGI.pm?

Yes and yes. What I am actually doing is extending the cookie-based access
control ("TicketMaster") outlined in the Apache Modules book[1]. If the user
attempts to access a restricted area and they don't have a cookie, they are
redirected to a login page (courtesy of an ErrorDocument 403). Upon
submission (POST) of the login page, if their credentials are good, they are
redirected to their original destination.

The original example in the book uses a refresh header, but that briefly
shows a "please stand by" page that I was hoping to avoid. It was working
fine, and then I made some changes that placed my "new CGI" instantiation
above the redirect, and it stopped working. I finally narrowed the problem
down to the program I posted.

I still think something is wrong here with CGI.pm and mod_perl's
interaction, but I guess I will go back to using the refresh header.

--David
--
1. http://www.modperl.com/book/chapters/ch6.html#Cookie_Based_Access_Control

can not redirect on POST w/ CGI.pm

[David Young]

I've found that if I post to this PerlAccessHandler, I get no response:

#
package Apache::Redirect;

use strict;
use Apache::Constants qw(REDIRECT);
use CGI ();

sub handler {
my($r) = @_;

my $q = new CGI();

$r->header_out(Location => "http://www.modperl.com/";);
return REDIRECT;
}

1;
#

If I comment out "my $q = new CGI();" then it works fine. Any ideas on what
is causing this?

Apache/1.3.14
mod_perl/1.24
CGI.pm/2.56

--David