Item10185: the strikeone validation page interferes with attachments

I do a topic, right click attach "open in new tab", 5 times, and then upload a different attachment per tab and some of the uploads file. The error on the website is: oswiki detected an internal error - please check your Foswiki logs...

It fails with:

| 2010-12-21T19:29:31Z warning | Can't call method "close" on an  undefined value at /var/fw/lib/Foswiki/Request/Cache.pm line 259.
at /var/fw/lib/Foswiki/Request/Cache.pm line 259
   Foswiki::Request::Cache::_loadUpload('Foswiki::Request::Cache=HASH(0x26e6438)', '/var/fw/working/tmp/passthru_5f4016f421a6de68aa043404190cee9c', 'abcdef.pdf') called at /var/fw/lib/Foswiki/Request/Cache.pm line 161
   Foswiki::Request::Cache::load('Foswiki::Request::Cache=HASH(0x26e6438)', '5f4016f421a6de68aa043404190cee9c', 'Foswiki::Request=HASH(0x198e6c8)') called at /var/fw/lib/Foswiki/Validation.pm line 264
   Foswiki::Validation::validate('Foswiki=HASH(0x1efdaf8)') called at /var/fw/lib/Foswiki/UI.pm line 457
   Foswiki::UI::logon('Foswiki=HASH(0x1efdaf8)') called at /var/fw/lib/Foswiki/UI.pm line 316
   Foswiki::UI::__ANON__() called at /usr/share/perl5/Error.pm line 416
   eval {...} called at /usr/share/perl5/Error.pm line 408
   Error::subs::try('CODE(0x16e23d8)', 'HASH(0x1efdf48)') called at /var/fw/lib/Foswiki/UI.pm line 435
   Foswiki::UI::_execute('Foswiki::Request=HASH(0x198e6c8)', 'CODE(0x1ee7fd8)', 'logon', 1, 'login', 1) called at /var/fw/lib/Foswiki/UI.pm line 277
   Foswiki::UI::handleRequest('Foswiki::Request=HASH(0x198e6c8)') called at /var/fw/lib/Foswiki/Engine/CGI.pm line 37
   Foswiki::Engine::CGI::run('Foswiki::Engine::CGI=HASH(0x19e7218)') called at /var/fw/bin/login line 24.
 |

In the log files. When this failure happens it always shows the "Strikeone" dialog first.

Also from IRC, using the chromium browser. Method is set to strikeone with defaults for the expert settings.

-- CarloKok - 21 Dec 2010

More info: I'm uploading rather large pdf files (1 mb). I'm switching tabs while uploading the files and have the "Create a link to the attached file" option set. The occurance of the strikeone dialog seems random to me, but the failure itself only happens when the filename has invalid characters in it (whitespace, dashes).

-- CarloKok - 21 Dec 2010

Looking at the Request/Cache module, it doesn't test that the file opened successfully. Not good practice, but something else is still going wrong. I've tried to recreate and have been unable to trigger the issue.

I've suggested enabling Asserts in bin/LocalLib.cfg - which enables more checking of the cached files.

-- GeorgeClark - 21 Dec 2010

I strongly suspect a race condition. Reasoning:

passthru files are only used when restoring parameters stored for a redirect. The OP has mentioned strikeone, so that redirect must have been a "suspicious change" redirect (unless there's something they're not telling us). A suspicious change is triggered when a POST doesn't match the correct validation key. Assuming JS has generated the key in the POST correctly, and the cookie hasn't changed between the POSTs, that means one of the keys was missing from the server (or already consumed) when the POST for one of the uploads hit it. Since the keys are stored in the CGI::Session, the inference is that two uploads clashed when trying to update that keystore.

I have not been able to reproduce it either, and am inclined to recommend the OP use the BatchUploadPlugin

-- CrawfordCurrie - 29 May 2014

Set to No Action. It's been 4 years without feedback. Please reopen if a reliable reproduction is found.

-- GeorgeClark - 31 May 2014

Commenting is disabled while not logged in