Bug: ModPerl shows same pages with different URL's

This is here because it isn't exactly a Twiki bug...

OS:	Win 2000 Professional SP 2
Webserver:	Apache 1.3.22
mod_perl:	mod_perl/1.26_01-dev
TWiki:	1 Dec 2001
Browser:	Internet Explorer 6.0

Steps to reproduce:

• 1. Navigate to TWiki main page.
• 2. Navigate to any other Twiki page.
• 3. Delete Browser instance.
• 4. Start new browser instance and enter URL of TWiki main page - see page from step 2 instead of Twiki main page.

mod_perl (see ModPerl) is loaded via the normal LoadModule/AddModule mechanism in the Apache .conf file, and the only other mention of it is in the TWiki/bin/.htaccess file:

<Files *>
  SetHandler perl-script
  PerlHandler Apache::Registry
  Options ExecCGI
  PerlSendHeader On
</Files>

Any experienced mod_perl users have any insight to this? FWIW, i've also posted to the mod_perl mailing list.

-- DavidLeBlanc - 02 Jan 2002

I was directed to the following by a mod_perl poster and wanted to add it in the event that it's relevent to this problem (from http://perl.apache.org/docs/1.0/guide/porting.html#Sometimes_it_Works__Sometimes_it_Doesn_t):

"When you start running your scripts under mod_perl, you might find yourself in a situation where a script seems to work, but sometimes it screws up. And the more it runs without a restart, the more it screws up. Often the problem is easily detectable and solvable. You have to test your script under a server running in single process mode (httpd -X).

Generally the problem is the result of using global variables. Because global variables don't change from one script invocation to another unless you change them, you can find your scripts do strange things."

There are also some remarks a little further down on this page about serious security issues surrounding the use of mod_perl with non-reentrant scripts.

-- DavidLeBlanc - 03 Jan 2002

Interesting - I'm adding this link to the ModPerl page. The debugging section at http://perl.apache.org/guide/porting.html#The_First_Mystery looks like a good way of pinning down the actual problem, which IMO may well be a TWiki bug.

-- RichardDonkin - 03 Jan 2002

Hi,

I'm facing this problem too. I added the writeDebug line below to the view script:

    my $thePathInfo = $query->path_info(); 
    my $theRemoteUser = $query->remote_user();
    my $theTopic = $query->param( 'topic' );
    my $theUrl = $query->url;
    TWiki::writeDebug( "View::main, obtained path_info($thePathInfo), remote_user($theRemoteUser), topic($theTopic), url($theUrl), envru($ENV{REMOTE_USER})" );

With the use case mentionned above, as well as in the following one, the variables that are not explicitely set (e.g. thePathInfo when calling /bin/view, or theRemoteUser when using non authenticated scripts) keep the value that were set by the last accessor.

Other use case:

• open one browser, edit a page to get authenticated
• open another browser and just call non-authenticated scripts: I'm known as the formerly authenticated user (as states the debug output and the 'you are xxx' bottom line of the VoidSkin.

I did some tries proposed at http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remedies_for_Inner_Subroutines , but without success.

Something strange in the whole thing: I could never see the warning mentioned ( Variable "$xxx" will not stay shared ), even when trying such things to simulate the nesting in the handler function:

( echo -n "sub XXX {"; cat view; echo "}" ) | perl -wc

My config:

• Win 2k
• Apache 1.3.28
• Activestate perl 5.6.1
• cygwin RCS 5.7
• TWiki Feb2003

Has someone some more infos / ideas?

-- JeanMarieClement - 30 Oct 2003

Do you have the directive, "PerlOptions ParseHeaders On" in the http.conf file? This directive is needed when scripts send HTTP header info.

Also be sure the directive "ScriptAlias /twiki/bin/ /URLpathto/twiki/bin/" in http.conf is commented out. ScriptAlias sets up the cgi-script handler; you don't want both handlers, cgi-script and mod_perl, set up on the same directory.

As an aside, I only got the error message "Variable will not stay shared" whenever /twiki/bin scripts required setlib.cfg and I hadn't placed the sitelib path in Window's registry.

After changing the registry, I had to comment out the statement, $twikiLibPath = '../lib'; to avoid "The system cannot find the path specified." errors. It seems that setlib.cfg is not required in twiki/bin/scripts if the path to find twiki.pm is set in Windows registry.

-- JamesWithey - 2 Nov 2003

I am using perl (mod_perl?) 1.28; so the " PerlOptions ParseHeaders On " is " PerlSendHeader On " for me, as I understood from http://perl.apache.org/docs/2.0/user/porting/compat.html#C_PerlSendHeader_
It was already set. I commented out the ScriptAlias, but it did not help.

-- JeanMarieClement - 03 Nov 2003

Re James' last para - you need to set an absolute pathname for the $twikiLibPath under mod_perl, but it's fine to set it in the registry if you prefer that.

-- RichardDonkin - 26 Jan 2004

Quick question for all of you...I have installed this plugin, and it works great. However, when I enable mod_perl on the server, the plugin breaks. I get these errors...

BeautifierPlugin Error: Unable to handle "cpp" syntax

It worked great before mod_perl was enabled, and now we can't even modify pages that have the plugin code??? help???

-- ChrisRizzo - 01 Jun 2005