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