---

Hello!...

A have one problem Too!... Im using a SunOS 5.9 Server, Apache/1.3.27 (Unix), Perl, v5.6.1 built for sun4-solaris-64int, and TWiki20040901 version.

but I have one problem with the RCS "DIFF", the problem is:

Warning: 'diff' program was found on the PATH but is not GNU diff - this may cause problems.

My diff version is : diff (GNU diffutils) 2.8.1 Copyright (C) 2002 Free Software Foundation, Inc.

My users cannot differentiate the versions from their contributions. As I can solve this problem? Somebody can help me?

---

Question

Hello!...

I'm new with Twiki...

I have one problem:

User clicks on link, then usergoing via http auth, list or topics displayed.

user selects topic, then clicks "Edit" link, then click to "save" button.

then user got a page:

Inproper use of the save script 

You cannot call this script directly, TWikibeta uses it internally. 

Some browser configurations occasionally send undefined data to the
 server. Don't worry, your changes are not lost. Just click the Back
 button on your browser and then try Save again. 

The other possibility is an internal error in TWikibeta configuration, 
or that you did not have write access to the directory or file that was
being edited. 

Please go back in your browser and save the topic. 

if user go back (browser button) and click "save" again - all going fine.

Does anyone have skills - how we can fix this problem?

anyone, please, help me.

I don't know, what is subject of problem: server configuration/twiki configuration/client problem?

but i notice about this problem more than twice.

output for testenv:

Test the environment for TWiki

Please read the TWikiInstallationNotes for more information on TWiki installation. 

Environment variables:

AUTH_TYPE Basic 
DOCUMENT_ROOT /home/cubehut/public_html 
GATEWAY_INTERFACE CGI/1.1 
HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */* 
HTTP_ACCEPT_ENCODING gzip, deflate 
HTTP_ACCEPT_LANGUAGE en-us 
HTTP_CONNECTION Keep-Alive 
HTTP_HOST cubehut.com 
HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2) 
PATH /usr/local/bin:/usr/bin:/bin 
QUERY_STRING  
REMOTE_PORT 3842 
REQUEST_METHOD GET 
REQUEST_URI /twiki/bin/testenv2 
SCRIPT_FILENAME /home/cubehut/public_html/twiki/bin/testenv2 
SCRIPT_NAME /twiki/bin/testenv2 
SERVER_PORT 80 
SERVER_PROTOCOL HTTP/1.1 
SERVER_SOFTWARE Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 
mod_bwlimited/1.4 PHP/4.3.7 FrontPage/5.0.2.2634a mod_ssl/2.8.18 
OpenSSL/0.9.7a 

CGI Setup:

Operating system: Unix (linux) 
Perl version: 5.8.1 
@INC library path: /home/cubehut/public_html/twiki/lib
/usr/lib/perl5/5.8.1/i686-linux
/usr/lib/perl5/5.8.1
/usr/lib/perl5/site_perl/5.8.1/i686-linux
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
. 

 Note: This is the Perl library path, used to load TWiki modules, 
third-party modules used by some plugins, and Perl built-in modules. 

TWiki module in @INC path:  
 OK, TWiki.pm found (TWiki version: 07 May 2004) 

Required Perl modules:  
 CGI (3.05) 
 CGI::Carp (1.28) 
 File::Copy (2.06) 
 File::Spec (0.87) 
 FileHandle (2.01) 

Optional Perl modules:  
 Algorithm::Diff (1.02) 
 MIME::Base64 (3.01) 
 POSIX (1.06) 
 Encode (1.9801) 
 Note: Optional module 'Unicode::MapUTF8' not installed - check TWiki
 documentation to see if your configuration needs this module.  
 Note: Optional module 'Unicode::Map' not installed - check TWiki
 documentation to see if your configuration needs this module.  
 Note: Optional module 'Unicode::Map8' not installed - check TWiki
 documentation to see if your configuration needs this module.  
 Note: Optional module 'Jcode' not installed - check TWiki documentation
 to see if your configuration needs this module.  
 Digest::MD5 (2.33) 
 Digest::SHA1 (2.10) 
 MIME::Base64 (3.01) 
 Net::SMTP (2.29) 

PATH_INFO:  

 Note: For a URL such as http://cubehut.com/twiki/bin/testenv2/foo/bar,
 the correct PATH_INFO is /foo/bar, without any prefixed path components. Test 

this now - particularly if you are using mod_perl, Apache or IIS, or are
 using a web hosting provider. The page resulting from the test link
 should have a PATH_INFO of /foo/bar.  

mod_perl: Not used for this script (mod_perl not loaded into Apache)  

User: cubehut 
 Note: Your CGI scripts are executing as this user. 
 Warning: Since your CGI script is not running as user nobody, you need
 to change the locks in the *,v RCS files of the TWiki distribution from
 nobody to cubehut. Otherwise, changes to topics will not be logged by RCS.  

Group(s): cubehut cubehut 


Test of TWiki.cfg Configuration:

$defaultUrlHost: http://cubehut.com 
 Note: This must match the protocol and host part (with optional port
 number) of the TWiki URL. 

$scriptUrlPath: /twiki/bin 
 Note: This must match the 'cgi-bin' part of the URL used to access the
 TWiki cgi-bin directory. 

$pubUrlPath: /twiki/pub 
 Note: This must be the URL of the public directory.This is not set
 correctly if the /twiki/pub/wikiHome.gif image below is broken:

$pubDir: /home/cubehut/public_html/twiki/pub 
 Note: This is the public directory, as seen from the file system. It
 must correspond to $pubUrlPath. 

$templateDir: /home/cubehut/twiki/templates 
 Note: This is the TWiki template directory, as seen from the file system.  

$dataDir: /home/cubehut/twiki/data 
 Note: This is the data directory where TWiki stores all topics. 

$mailProgram: /usr/sbin/sendmail -t -oi -oeq 
 Note: This is the mail program TWiki uses to send mail. 

$rcsDir: /usr/bin 
 Note: This is the directory where RCS is located. 

RCS Version: 5.7 
 Note: This is the version of RCS which will be used. 

$lsCmd: /bin/ls 
 Note: This is the file list program TWiki uses to list topics. 

$egrepCmd: /bin/egrep 
 Note: This is a program TWiki uses for search. 

$fgrepCmd: /bin/fgrep 
 Note: This is a program TWiki uses for search. 

$safeEnvPath: /bin:/usr/bin 
 Note: This is used to initialise the PATH variable, and is used to run
 the 'diff' program used by RCS, as well as to run shell programs such as 

Bourne shell or 'bash'. 


Path and Shell Environment

Original PATH: /usr/local/bin:/usr/bin:/bin 

 Note: This is the PATH value passed in from the web server to this
 script - it is reset by TWiki scripts to the PATH below, and is provided
 here for comparison purposes only.  

Current PATH: /bin:/usr/bin 

 Note: This is the actual PATH setting that will be used by Perl to run
 programs. It is normally identical to $safeEnvPath, unless that variable
 is empty.  

diff: GNU diff was found on the PATH - this is the recommended diff tool. 
 Note: The 'diff' command is used by RCS to compare files.  

User Authentication
htpasswd Format Family: htpasswd 
htpasswd Encoding: crypt 
htpasswd Filename: /home/cubehut/twiki/data/.htpasswd 
 Note: only some combinations of Format, Encoding and Filename are valid,
 and fewer are tested 

thank you!

vladimir

Environment

TWiki version:	TwikiBetaRelease2004x05x07
TWiki plugins:	DefaultPlugin,
Server OS:	Linux 2.4.26 #1 SMP
Web server:	Apache/2.0.46
Perl version:	v5.8.1
Client OS:	Win XP SP1
Web Browser:	IE 6.0

-- VladimirPlotnikov - 17 Jul 2004

Answer

The error message you describe is the result of the "save" script being invoked without the "text" parameter being set on the query. If you modified your "edit" or "preview" templates this might happen.

There have been problems reported running TWiki with Apache 2.0, so search the Codev web to see if this problem has been encountered before.

Check your apache log files for errors. Also check twiki/data/warning.txt.

Finally I note that you are executing as user "cubehut". I assume you have corrected the locks on the files in the data directories, and set the permissions correctly as described in the installation documentation?

-- CrawfordCurrie - 19 Jul 2004

Answer

Thank you for reply.

I cannot understand one: if user click "back" in browser and press "save" again (without preview) all going fine. no oops screen appears.

Then, after this, all savings going fine, until user keeps browser window opened.

I use next way for "fast save" feature - input type button in "edit" template and onclick event invokes next javascript:

function fastsave() {
        form=document.forms[0];
        form.action="%SCRIPTURLPATH%/save%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%/%TOPIC%"}%";
        form.submit();
}

also, I inspect file twiki/lib/TWiki/UI/Save.pm

this oops screen called from

if( ! ( defined $text ) ) {
    TWiki::UI::oops( $webName, $topic, "save" );
    return;
} ....

so, in some cases we cannot receive POST variable from client? or from server? May be anyone fix same problem?

vladimir.

russia, novosibirsk

-- VladimirPlotnikov - 21 Jul 2004

I too occasionally see this problem (retry works fine), but I have not found an answer.

-- MartinCleaver - 08 Sep 2004

I have the same problem. I did a packet dump using ethereal. The packet payloads are identical for the failed and the successful re-save. Both attempts send the authorization information correctly and the packets are ACK'd by the server on both occasions. The Apache error log shows no details for the failed attempt and I can't get to the suexec log as I don't have root access.

-- GeoffJohnston - 12 Sep 2004

I tried running DataDumper on bin/save and got these results on first session save and retry save after hitting the back button. I did a dump on $query at line 39 my $query = new CGI;

16 Sep 2004 - 00:57 The query var is $VAR1 = bless( {
                 '.parameters' => [],
                 '.charset' => 'ISO-8859-1',
                 '.fieldnames' => {},
                 'escape' => 1
               }, 'CGI' );
                                                                                
16 Sep 2004 - 00:58 The query var is $VAR1 = bless( {
                 '.parameters' => [
                                    'text',
                                    'formtemplate',
                                    'topicparent',
                                    'cmd',
                  ...

What does this code at line 43 do in the save script? It evaluates to undefined on every save. Is there a parameter called topic? my $theTopic = $query->param( 'topic' );

-- GeoffJohnston - 16 Sep 2004

Problem seems to be with Firefox 0.9.3 and some versions of Explorer I have found so far. The problem seems to occur when Firefox tried to resend the cached form data to the server after the 401 authentication request. If I use a simple form and get a script to echo back the environment variables, I get:
REMOTE_USER GeoffJohnston
REQUEST_METHOD greeting=Hello+World%0D%0APOST
REQUEST_URI /~johnston/test/echoargs.cgi

The URI is http://www.cs.dal.ca/~johnston/bad and the script sits in a .htaccess protected directory. user:my pass:ruin On resubmission I get this response:

REMOTE_USER GeoffJohnston
REQUEST_METHOD POST
REQUEST_URI /~johnston/test/echoargs.cgi

The error seems to be a confused browser doing a GET with the form data as I sometimes get "URI too Large" errors when submitting edited topics with large amounts of text.

The problem can be cured by removing the name= attributes and replacing them with id= tags. Although the name= passes the W3 validator for XHTML1.0, there is a mention on the W3 forms page (http://www.w3.org/TR/xhtml1/#h-4.10) saying that name is deprecated, though if it is used it should contain the same information as the id tag. ie name="greeting" id="greeting". There is also a form script with id tag used instead of name= http://www.cs.dal.ca/~johnston/good
Caveat Emptor...I'm a newbie, so I might have a bad case of 2 + 2 = 5.

-- GeoffJohnston - 19 Sep 2004

A scientifically minded newbie, nevertheless. You hit three alarm bells with me; request size on GET, name versus id, and Apache 2. I have often run into mysterious errors that turned out to be down to the request size. However I use Firefox 0.9 all the time and have never seen the error, so I wonder if it is actually the server that has the problem and that the choice of browser is just tipping the request size over some limit. I use Apache 1.3, not Apache 2.

However I don't really understand your debugging above. You say you dumped the packets using ethereal and the packet content was identical between the two requests, but then you say the dumping script generated different output for the two requests; how can that be?

BTW topic is a valid parameter, and does get used, though I can't recall when - undefined is a perfectly valid value for it.

• For the record, the topic input field is used by the PatternSkin's WebTopBar for that "Jump" box on the top right of a rendered TWiki page. Also, I had a problem with saving (much worse symptom - it would actually replace both the .txt and .txt,v files with blank files, erasing all history and failing to save the current changes) - I tracked it down to my using SpeedyCGI with the TWiki. In my case, there would be some conflict over file handles given to different instances of the SpeedyCGI backend. In this case, it may be some persistence of a CGI object over multiple sessions. In any case, be wary of these types of accelerators. -- OrrBernstein - 29 Nov 2004

-- CrawfordCurrie - 19 Sep 2004

I resolved my problem by installing apache2.0.51 on my web space and leaving my twiki filesystem untouched. The school system uses apache 1.3.31 The new version is different in that it is all the data is pushed and HTTP 1.1 is not used.

When I said earlier that the packets were identical, I should have said that form data in the pachets was identical for good and failed saves. I don't know why it only afffects the first save in each web... but I found it worked properly on the original server with links and w3m text browsers which both use http 1.0. If you have root access on the server, you could always try editing httpd.conf and forcing a HTTP1.0 response to see what effect that has. In the end I wasn't sure how much was a problem with the server and how much was a buggy implementation on the client side. Oh, the original server worked fine when I accessed it through our squid proxy; once again this was a HTTP 1.0 transaction. I'm also not sure about suexec. My scripts are suexec'd and the suexec apache page says that only a "cleaned down" safe set of environmental variables are passed to the script. I don't know if ths has any effect on the problem or just a red herring.

-- GeoffJohnston - 27 Sep 2004

One of my users has revealed that he never had the problem when he ran Windows ME (with at least IE5.5) but he does have the problem everytime immediately after authenticating now that he is using XP SP2+ IE 6.0. I have never seen the problem using Firefox (1.0).

It might be that this is why twiki contributors seldom see the problem - we are too discerning to be affected!

-- MartinCleaver - 08 Dec 2004

I've had the problem too, but my cause has been different to the previous text. Our host was www.espp.org.uk, which the TWiki.cfg had in it. The primary domain the webserver was reporting as then changed to www.earlysupport.org.uk. So if you logged into the twiki using the espp one view and other scripts ran fine, but the save one didn't. When I changed the cfg file to www.earlysupport.org.uk the problem went away only if users logged into twiki using the www.earlysupport.org.uk. If users used www.espp.org.uk then the server name changes to www.earlysupport.org.uk ... perhaps this name changing causes the browsers not to send the correct information during the form submit?

-- RudiBierach - 06 Jan 2005

Ah, useful. Thanks Rudi.

On my server it was changing from example.com to www.example.com - I've asked the site users to tell me whether this solves the problem for them.

Cheers, M.

-- MartinCleaver - 07 Jan 2005