Item12367: Foswiki::Request::Cache breaks uploads with filenames that contain special characters
Priority: Normal
Current State: Closed
Released In: 1.1.7
Target Release: patch
When requests with file uploads are cached (e.g. due to a login or StrikeOne verification), the cache uses the originally submitted filename
in URL-encoded form from the form data as the filename for some temporary files. However, when loading, it attempts to use the
unencoded form of the original filename for reading the temporary files. This results in an ugly "internal error" message.
Example:
- User uploads with filename
c:\test.txt
- Temporary filename is something that contains
c%3a%5ctest.txt
- When 'applying' the cache, the code attempts to read the upload info from a temporary filename containing
c:\test.txt
instead
The fix is simple: use the encoded form of the filename when loading uploads.
--
JanKrueger - 24 Jan 2013
I'm not sure this is correct.
To test I did the following
- Created a file woo%hoo#@.wav
- Browsed to the attach upload screen
- Deleted my session cookie to force a login
- Clicked upload
- The upload fails with a message that the file is empty.
If I repeat the process after being logged in, the upload runs, but the %, # and @ are filtered out fo the filename, and woohoo.wav is attached.
I also changed the
NameFilterIn
to remove the % and tried uploading woo%hoo.wav. Still fails complaining about an empty file:
Attention
Either you did not specify a file name, or the file you are trying to upload woo%hoo.wav has no content. You may not upload an empty file.
It does solve the internal error though. If your fix is reverted it fails with:
Can't call method "close" on an undefined value at /var/www/foswiki/trunk/core/lib/Foswiki/Request/Cache.pm line 259.
at /var/www/foswiki/trunk/core/lib/Foswiki/Request/Cache.pm line 259
Foswiki::Request::Cache::_loadUpload('Foswiki::Request::Cache=HASH(0x804e2e8)', '/var/www/foswiki/trunk/core/working/tmp/passthru_ac3efc8bd264...', 'woo%hoo#@.wav') called at /var/www/foswiki/trunk/core/lib/Foswiki/Request/Cache.pm line 161
Foswiki::Request::Cache::load('Foswiki::Request::Cache=HASH(0x804e2e8)', 'ac3efc8bd26448067ba0c2911e9a0018', 'Foswiki::Request=HASH(0x84fdf98)') called at /var/www/foswiki/trunk/core/lib/Foswiki/UI.pm line 236
Foswiki::UI::handleRequest('Foswiki::Request=HASH(0x84fdf98)') called at /var/www/foswiki/trunk/core/lib/Foswiki/Engine/CGI.pm line 41
Foswiki::Engine::CGI::run('Foswiki::Engine::CGI=HASH(0x81e6820)') called at login line 24
--
GeorgeClark - 25 Jan 2013
I'm not sure what is going on here. After discussing on IRC, using the browser back button to upload a 2nd file is working fine. And that is by far the more likely scenario, so I think this is fixed. The Empty File issue is something else I guess. I was trying to simulate a session timeout though again that is pretty unlikely. I think that this can be set to waiting for release.
--
GeorgeClark - 25 Jan 2013
As previously mentioned on IRC, simulating a session timeout by deleting the FOSWIKISID cookie worked fine for me (my test filename contained a space (%20) character and an umlaut). The main difference we identified on IRC was that I was using ApacheLogin whereas George was using TemplateLogin. I haven't had time to test with TL yet, but I suspect that if that's what caused the "empty file" issue, it involves a separate bug. I'm okay with moving this item forward, too, and since nobody else seems to be involved here, I'm updating the CurrentState field.
--
JanKrueger - 27 Jan 2013