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.

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"

-- 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)

- 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 (/)...

WN

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.

CC

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

SVN 7349

CC