Forum OpenACS Development: Naviserver Post Body Lost if Over a Certain Size

We are tracking down a problem that was recently revealed.

We have an Xowiki page with a very long content body. Over 87000 characters.

When attempting to edit and save this page, the POST body is dropped and does not appear to be received or processed by the request processor or xowiki package. Logging in the rp_handler procedure and index.vuh of xowiki show no post data is in ns_conn query or ns_getform.

I also added logging to ns_getform procedure to see if I could figure out what was happening from that direction but it does not reveal anything I can find.

For example this debugging line in the index.vuh for xowiki shows in most cases the form data is received, but in the case of very long form data it is empty.

::$package_id log "--starting... [ns_conn url] [ns_conn query] \
form vars = [ns_set array [ns_getform]]

I checked the maxupload setting that specifies if post data is written to a temporary file. I tested 10000 - 100000 (original settings) - 1000000

Increasing the maxupload setting in the config file to 1 million bytes does solve the problem. Is this a problem we should try to fix. Should a large form upload (without a file attachment, just a textarea) fail if it is larger than this setting?

Posted by Gustaf Neumann on
do i understand correctly, the problem happens with POST requests with large textarea content, but not with uploaded files. My suspicion is that it has to do with the content-type, that the browser switches between *www-form-urlencoded" and "multipart/form-data". can you check the content-type?

With which version of naviserver and which browser are you testing?

Posted by Gustaf Neumann on
Never mind about the detail info: i was able to reproduce the issue. The problem was - as suspected - the handling of www-form-urlencoded with spooled content. This is now fixed in the updated version of NaviServer.
Posted by Dave Bauer on
Thanks for your quick response that was very helpful!
Posted by Dave Bauer on
Gustaf, Thanks for that fix. We added the form.tcl to our naviserver . Should that work? We are getting an error message of

wrong # args: should be "try code ?catch? ?handler? ?finally? ?cleanup?"
while executing
"try {
set content [read $fp]
#ns_log warning "===== ns_parseformfile reads $file $form $contentType -> [string length $content..."
(procedure "ns_parseformfile" line 17)

We added the form.tcl so we did not have to recompile naviserver. I didn't notice any changes to other files for this fix.

Posted by Gustaf Neumann on
what version of "try" are you using? "try" is builtin in tcl 8.6 [1] and there is an emulation in tcllib for 8.5. None of these versions provide the error message above.