Question
I recently changed my configuration to use mod_perl. I though everything was fine for a while until I started to see unresolved %VARS% showing up on my pages. It turns out that when I run mod_perl pages with text in excess of around 5k (5,899 specifically) bytes get truncated when edited. This is the most serious when a user edits the Preferences page and you loose most of your config variables. Can you suggest any way to stop this from happening?
Environment
--
WilliamReichardt - 28 Aug 2003
Answer
Have you checked
ExtraneousLineInHttpHeader, listed in
KnownIssuesOfTWiki01Feb2003? Also, have a look at
MozillaAndModPerlConflict which links to some related pages.
--
RichardDonkin - 29 Aug 2003
I looked at
ExtraneousLineInHttpHeader but did not think it fit my problem as I lost over 500 characters in my posted page. Is this what is meant by erratic behavior? I am running IE as a client in this case so I don't think
MozillaAndModPerlConflict applies. What has helped so far is a work around which is to only use mod_perl for the view script and let everything else go through the CGI way for now. This gives me speed for the casual viewer which really helps, I just wait for posting content. This snippet in my httpd.conf makes only view use mod_perl.
NameVirtualHost ###.###.###.###
ServerName sample.org
DocumentRoot "/var/www/sample.org"
ScriptAlias /sample.org/bin/ "/var/www/sample.org/bin/"
Alias /wiki/ "/var/www/sample.org/"
<FilesMatch "^{view}$">
SetHandler perl-script
PerlHandler ModPerl::Registry::handler
PerlSendHeader On
#PerlOptions +ParseHeaders
Options +ExecCGI
</FilesMatch>
--
WilliamReichardt - 02 Sept 2003
I linked to the Mozilla page because of its links to
UnfinishedCloseHTMLTagUnderModPerl etc - also, the bit about...
IncompletePagesOnDec012000Rel points to an Apache bug with a useful test script that should determine whether this is a TWiki problem. Since the Apache bugs server is broken right now, here's a
Google cached version of ApacheBug:3089.
It would be well worth commenting on
Codev.ModPerl and linking to this page, so that you get more feedback from mod_perl users. Failing that, try asking on a mod_perl email list, but I know there are people using TWiki fine under mod_perl so hopefully the TWiki community can help.
--
RichardDonkin - 02 Sep 2003
I'd like to put in a "Me Too" on this one. I just noticed this with my
TWikiPreferences. The last edit I did was before I put TWiki back to using mod_perl. It never used to happen with Dec 2001 and RH 7.3/Apache 1.3. After a couple of months with Feb 2003 I decided it was time to use mod_perl again. This is the first problem I noticed in the almost 2 months since.
My environment is pretty much the same as above, except for a newer kernel (2.4.20-27, but I doubt that matters). I've tried it using Konqueror 3.1.4 on Fedora Core 1 and both Firebird 0.7 and IE 6 SP1 on Windows 2000 SP3. I get the same behaviour on either platform, so I don't think it's a client issue. On IE, the Preview page itself is basically a white background and nothing else though. For now, I guess I'm stuck with the mod_perl view-only workaround suggested above...
--
BillSmargiassi - 12 Jan 2004
Have you tried the possible fix in
ExtraneousLineInHttpHeader? This is also included in the latest
TWikiBetaRelease, though that includes many other changes too.
--
RichardDonkin - 13 Jan 2004
No, I hadn't because it didn't seem to apply to this at all. It didn't only happen with IE6, that was just the worst experience I found. It also happens with Konq and Firebird.
Just for completeness (and since the patch is already in the next beta) I made the changes. I still consistently lose the contents after "Email and Proxy Settings", even with a full Apache restart. IE6 still shows a completely blank page. By completely blank, I mean:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>
<BODY></BODY></HTML>
--
BillSmargiassi - 13 Jan 2004