• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Due to the referrer-script bin/viewfile the filename proposed when saving an attachment to the disc is the name of the topic. This behavior is somewhat annoying. wink

Maybe its possible to change the URL within the http header to something which ends in the filename instead of in the topicname. -- OK - 20 Oct 2005

I believe setting the "Content-Disposition:attachment;filename=" header can take care of this problem, see http://www.sitepoint.com/print/file-download-script-perl for an example. You're right: Current status is "somewhat annoying" wink

-- TWiki:Main.SteffenPoulsen - 20 Oct 2005

The Content-Disposition-header is set correctly when downloading a file by clicking on its link. I don't know, if the behavior described above can be supressed at all when using the "Save As"-dialog from the context menu of your browser. -- OK - 21 Oct 2005
Hmm I am not able to see the Content-Disposition-header in my setup, when inspecting traffic - neither using a proxy or in direct communication (using "Live HTTP headers" with Firefox or "HttpWatch Explorer Bar" for IE). I still believe setting the header will solve the problem. Are you using any plugins or i.e. apache extensions that might be adding the header? Are you able to upload a trace of your download, including the Content-Disposition header? Attached a trace of the current situation from this point of view (see above) smile

- Anyway, it seems there's a difference between browsers .. generally the redirection doesn't impact the filename with IE (current situation), but with firefox you get the "wrong" filename.

-- TWiki:Main.SteffenPoulsen - 21 Oct 2005

Shall we close this bug? Since this is a browser specific issue, I would say yes. -- OK - 30 Oct 2005
no, don't close this bug yet (it's definitely broken and not fixed). the trick is to include the filename as the last part of the url, eg, instead of http://tinderbox.wbniv.wikihosting.com/cgi-bin/twiki/viewfile.cgi/Sandbox/WebHome?2468byzantine_square_web.jpg=rev;1=filename;2468byzantine_square_web.jpg= , it should be http://tinderbox.wbniv.wikihosting.com/cgi-bin/twiki/viewfile.cgi/Sandbox/WebHome/2468byzantine_square_web.jpg?2468byzantine_square_web.jpg=rev;1=filename;2468byzantine_square_web.jpg= (except that doesn't work either, because something (viewfile?) is being too smart, but this is the technique to make it work)

also, currently the file doesn't download when i click on its name, instead i get a directory listing (including with the ,v files)

i tried adding the filename to the url, but some code after it "cleaned up" the dots (.) into slashes (/)...


well, I also had a go at this and i couldn't figure out a fix -- so what next? (if there is nothing known, it'll be deffered) -- SD

Hmm, I'm not sure I get this. Problem lies with the $session->redirect(), so why not just cut it out of the equation, if a rev tag is in the request link at all? This means chaning line 359 in lib/TWiki/UI/View.pm:

-    if( $rev && $rev ne $topRev ) {
+    if( $rev ) {

This means a redirect occurs only if version is not specified - and filenames are saved as expected from TWiki-created links in all browsers.

Could there be a performance issue in letting TWiki do the sending instead of the webserver? (I don't believe so).

Btw: Putting paragraphs around the filename wouldn't hurt, I guess, line 368:

                -Content_Disposition => 'inline;filename='.$fileName);
                -Content_Disposition => 'inline;filename="'.$fileName.'"');

-- SP

The if( $rev && $rev ne $topRev ) is done on purpose to speed up download if the requested rev is the top rev.

-- PTh

In my view favor goes to firefox compatibility - viewfile should finish its job properly, once started. At least at our installation we won't have any bottleneck here, attachment hits are few, and viewfile maxes out fast ethernet easily on standard hardware. I might see a problem for an installation with many lengthy simultaneous downloads, each tying up i.e. a thread from a limited SpeedyCGI-ressource pool .. but not in any kind of "standard" setup.

-- SP

Additional; JoanTouzet pointed out on IRC that the redirect breaks in other ways - it relies on the the file being open access, and when using template login for example, it won;t be.

The logical solution is to dump the redirect (which also simplifies the code). There will be a small performance penalty.


Actually, I'm not convinced there is a penalty, since it cuts out the redirect.

SVN 7349


Summary Saving attachments to disc proposes wrong/misleading filenames - WILL
ReportedBy OliverKrueger
AppliesTo Engine
Priority Urgent
CurrentState Closed

Checkins 7349
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2005-11-07 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback