Question

I get some apparently erratic "Incorrect parameters to the save script" errors on saving topics. Subsequent saves (even without changes!) either go through or bump into the error again.

I couldn't find any Bug report or Support question online; nevertheless, Kenneth Lavrsen has brought the subject up at least three times in the past (check IRC logs).

http://koala.ilog.fr/twikiirc/bin/irclogger_log_search/twiki?search=Incorrect+parameters&action=search&error=0

Environment

-- RenatoSerodio - 05 Sep 2006

Answer

If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

Experiencing the same problem. Notably I don't see the issue when I use firefox. I find with IE that I get the 'incorrect parameters' message when I try and save the second or third time. With Firefox I can save multiple times without any issues.

My setup is the same as above. Running mod_perl and mod_ntlm as well.

-- NathanReeves - 06 Sep 2006

Indeed, IE appears to be the issue; below is a topic I use in the Sandbox: repeatedly adding and removing the exclamation point before JosephOfArimathea eventually causes the error on IE, but not on Firefox.

The error comes up both with and without mod_perl (which I prefer to leave out, since it tends to conflict with other things, and doesn't add that much to performance). I'll had that I do have a number of plugins running, as well as a SSPI (in apache) -based auth method. As an example, TagMePlugin is 'discriminated' by IE: since in the generated html a <tags >= attribute is set, IE bombs the Print view.

---+<nop>%TOPIC%

---+!! JosephOfArimathea 

The Legendary BlackBeastOfAaaaarrrrrggghhh


---++ Last Contributers
%CONTRIBUTORS{nodups="on" last="5"}%

-- RenatoSerodio - 06 Sep 2006

This happens to me with Firefox. It occurs if my authentication cookie has expired since I last saved and now I click the "Add" button on a comment form or the Save button in an Edit session.

I usually just go back after re-authenticating and click Save or Add again but I agree it's a weird behaviour.

-- VickiBrown - 06 Sep 2006

Thanks for reporting that Firefox is also affected. I'd say that, since there is no bug report on this, the standard TWiki authentication does not generate this problem, though schemes based on LDAP, NTLM or SSPI do.

The thing is, how is one to debug such a thing? I couldn't find anything related on the web..

-- RenatoSerodio - 14 Sep 2006

The message usually means that a GET or POST request has been passed to the server without required parameters. The save script requires a number of parameters, and rebels if it doesn't get them.

The questions I would be asking are:

1. Is this a GET or a POST?
2. Was it immediately preceded by another identical request
   • Suggests known Konqueror buyg
3. Was it a redirect?

-- CrawfordCurrie - 18 Sep 2006

No more feedback, closing after more than 30 days...

-- PeterThoeny - 24 Oct 2006

IE6 and 7 by default attempt to re-authenticate on every POST when using NTLM. Apparently to save bandwidth IE does not actually include the POST content until it can provide the NTLM_AUTH message. It assumes that when it provides a NTLM_NEGOTIATE message the web server will respond with a 401 Not Authorised with a NTLM_CHALLENGE message in the headers. mod_auth_sspi v1.0.4 and earlier ignore the NTLM_NEGOTIATE and blindly accept the empty POST. Twiki then chucks a hissy-fit at the lack of save parameters which is what your seeing here.

I have exactly the same problem and unfortunately I cannot find a solution at this point that will work for all POSTs. I have found that applying the registry fix documented at http://support.microsoft.com/kb/251404 will help with save POSTS, however POSTs to the REST mechanism still fail, which means you can't use the Wysiwyg editor with NTLM/SSPI. For some reason the NTLM_AUTH token sent along in the POST to REST is incorrect for 50% of my users (including my boss - ironic) and mod_auth_sspi will respond with a 401 error and put a (OS 87)The parameter is incorrect.... user unknown, reason: cannot generate context error in Apache's error log.

-- LeeRyman - 01 Dec 2008

Thanks Lee for the forensic work. Re-opening to see if someone picks this item up.

-- PeterThoeny - 01 Dec 2008

Did a bit more research, particular into the mechanism that performs the asynchronous POST submission. The TinyMCEPlugin appears to use the stock-standard XMLHttpRequest mechanism. It seems that when using NTLM you may only use a XMLHttpRequest object once - A second request using the same object will not work correctly and elicit the symptoms described. This matches my experience in which the first time you edit using the Wysiwyg editor it loads up the content fine. Subsequent attempts (after saving or cancelling) would (depending on the configuration of the Apache SSPI module) either produce an empty editor window (with a log entry regarding uninitialised variables) or a persistent "Loading, Please Wait".

Robert Nyman has more info on it including a possible solution (bizarre similarity in last name besides). I will give it a test and get back to you.

-- LeeRyman - 03 Dec 2008

I have managed to eliminate the issue by removing the line within twiki_tiny.js that sets the Connection header to "close" on the XMLHttpRequest. This is about line 83 in twiki_tiny_src.js. I also required the declaration "SSPIPerRequestAuth On" within my apache configuration within the Directory sections for /twiki/pub and /twiki/bin.

The first change fixes IEs behaviour with the REST mechanism and POSTs. The second allows the server to handle the zero-length POST and NTLM_NEGOTIATE messages in general by always attempting re-authentication. This fixes the save scripts as well. I have found that the aforementioned registry change documented at http://support.microsoft.com/kb/251404 Is no longer required with these changes.

It would be nice for the mod_auth_sspi module to handle the NTLM_NEGOTIATE header automatically, but this works for the moment. Of course, it would be even nicer if IE was consistent in following its own standards

A quick search on TWiki reveals that SergeiKlink had already come across this. Kudos to him.

I'd like some confirmation before closed if possible. Hope this helps

-- LeeRyman - 03 Dec 2008

Thank you very much for researching this and for posting a fix. I filed TWikibug:Item6141 to track this. If you are a developer you could join the TWiki community. ReadmeFirst gets you started.

-- PeterThoeny - 04 Dec 2008