Download of PDF files does not work

[izzy]

I uploaded a PDF file to the Downloader. If was saved fine (when I go to the server using ssh and check, the file still is intact). However, wen I click it in the downloader, it asks me (with the correct mimetype) to open it with the PDF viewer - but the PDF viewer just says "broken". Right-click, save as - asks me to save 3.htm and says type is HTML file.

Suggestion: You simply store the uploads as "numbers", i.e. the file names are just the internal ID used. Guess this is needed to reference them. But reference would also work if you keep at least the extension of the file, e.g. "3.pdf". This could avoid the problem. Not sure whether other extensions are affected as well - seems to work fine at least for *.exe when downloaded directly (left-click). But right-click, save as has the same problems here, since no extension is given (so the browser cannot determine the mime type). Just tested again: When I do not select to directly display it in the viewer (after a left click) but to save it to disk, the file is kept intact. Tested with Firefox on Windows and Linux.

I would like even more to see the filename when I visit the directory. On the command line, I cannot tell what file it is otherwise. To keep the reference easy, this could be achieved by either

• naming the file <id>-<original filename>
• saving the file as <id>/<original filename>

In both cases, the file extension would also be kept intact. But please count the download problem as the main issue, and the rest as nice-to-have ;)

[Petr Škoda]

Hi!

I've made some tests, but I don't have such problem on any of my testing machines. So as the first please attach here that file broken after download.

Saving by right clicking should at least change name of that file before it starts downloading (there is redirect) but I must agree that in some special cases there could be problem with extension in when saving through right click but there shouldn't be this problem with PDF files.

The name of file saved in Downloader's data dairectory cannot affect this because the file is not served to user directly by webserver but Downloader (Trac) makes it it's own way which is independent on naming in filesystem.

Plese give me some details of your webbrowser, exact Trac version and branch of DownloaderPlugin.

Thanks.

Replying to izzy:

I uploaded a PDF file to the Downloader. If was saved fine (when I go to the server using ssh and check, the file still is intact). However, wen I click it in the downloader, it asks me (with the correct mimetype) to open it with the PDF viewer - but the PDF viewer just says "broken". Right-click, save as - asks me to save 3.htm and says type is HTML file.

Suggestion: You simply store the uploads as "numbers", i.e. the file names are just the internal ID used. Guess this is needed to reference them. But reference would also work if you keep at least the extension of the file, e.g. "3.pdf". This could avoid the problem. Not sure whether other extensions are affected as well - seems to work fine at least for *.exe when downloaded directly (left-click). But right-click, save as has the same problems here, since no extension is given (so the browser cannot determine the mime type). Just tested again: When I do not select to directly display it in the viewer (after a left click) but to save it to disk, the file is kept intact. Tested with Firefox on Windows and Linux.

I would like even more to see the filename when I visit the directory. On the command line, I cannot tell what file it is otherwise. To keep the reference easy, this could be achieved by either

• naming the file <id>-<original filename>
• saving the file as <id>/<original filename>

In both cases, the file extension would also be kept intact. But please count the download problem as the main issue, and the rest as nice-to-have ;)

[izzy]

Replying to peca:

I've made some tests, but I don't have such problem on any of my testing machines. So as the first please attach here that file broken after download.

Since it is from a closed environment, I don't want to put that file public. If you send me a mail to izzysoft at qumran dot org, I'll send you the broken file. Looks like it was not handled as binary...

Saving by right clicking should at least change name of that file before it starts downloading

Sure, I did that. But even by a direct click, the viewer reported a broken file. I will provide you an URL by mail as well.

(there is redirect) but I must agree that in some special cases there could be problem with extension in when saving through right click but there shouldn't be this problem with PDF files.

As I wrote, I even have this problem with .exe files when using right click.

The name of file saved in Downloader's data dairectory cannot affect this because the file is not served to user directly by webserver but Downloader (Trac) makes it it's own way which is independent on naming in filesystem.

I thought so, too - but obviously it still gets broken, though.

Plese give me some details of your webbrowser, exact Trac version and branch of DownloaderPlugin.

Trac 0.10.4 and the latest code from SVN. Browsers have been Firefox on Windows (don't know the exact version, since it was my father on the phone reporting this and I forgot to ask - but must be 2.x) and Firefox 2.0.0.12 on Ubuntu Linux. Using Konqueror (3.5.6) I have the same problem: Acrobat cannot read the file (neither left click nor right click and save). Funny though that xpdf still can read the file - but the original (before upload) was readable by Acrobat, too. And if I simply scp the file back, Acrobat still can read it.

[Petr Škoda]

My e-mail is pecast_cz at seznam dot cz. So send me the file. And are you sure you're using Downloader branch for Trac 0.10? (like this: easy_install ​http://trac-hacks.org/svn/tracdownloaderplugin/0.10/)

Replying to izzy:

Replying to peca:

I've made some tests, but I don't have such problem on any of my testing machines. So as the first please attach here that file broken after download.

Since it is from a closed environment, I don't want to put that file public. If you send me a mail to izzysoft at qumran dot org, I'll send you the broken file. Looks like it was not handled as binary...

Saving by right clicking should at least change name of that file before it starts downloading

Sure, I did that. But even by a direct click, the viewer reported a broken file. I will provide you an URL by mail as well.

(there is redirect) but I must agree that in some special cases there could be problem with extension in when saving through right click but there shouldn't be this problem with PDF files.

As I wrote, I even have this problem with .exe files when using right click.

The name of file saved in Downloader's data dairectory cannot affect this because the file is not served to user directly by webserver but Downloader (Trac) makes it it's own way which is independent on naming in filesystem.

I thought so, too - but obviously it still gets broken, though.

Plese give me some details of your webbrowser, exact Trac version and branch of DownloaderPlugin.

Trac 0.10.4 and the latest code from SVN. Browsers have been Firefox on Windows (don't know the exact version, since it was my father on the phone reporting this and I forgot to ask - but must be 2.x) and Firefox 2.0.0.12 on Ubuntu Linux. Using Konqueror (3.5.6) I have the same problem: Acrobat cannot read the file (neither left click nor right click and save). Funny though that xpdf still can read the file - but the original (before upload) was readable by Acrobat, too. And if I simply scp the file back, Acrobat still can read it.

[izzy]

Yes, I installed the plugin exactly like that. Mail with the original and the broken file is on its way. As I wrote: The downloaded file is 1.1kB larger than the original. However, the uploaded file has exactly the same size (i.e. is kept intact).

[izzy]

Arg! I just opened the downloaded PDF in vi. Have a look at the end of the file, there is a bunch of HTML added immediately after the ending %%EOF showing an server error (500). So here comes the "bad guy" from the trac log:

2008-03-04 08:35:44,669 Trac[model] WARNING: File '/usr/lib/python2.4/site-packages/TracDownloader-0.1-py2.4.egg/tracdownloader/mime_list.py' should be writable to use modified MIME list from mime_list.txt.
2008-03-04 08:35:45,555 Trac[main] WARNING: 500 Internal Error (No handler matched request to /download .)

I made that file writable by the web server now. No change - since the 500 Internal error persists with the "No handler matched".

[izzy]

P.S.: Note the handler in the error message is "/download", while it should read "/downloader". Maybe it was thought to read "/downloader/download", and was not correctly referenced?

[izzy]

P.P.S.: When I enable the captcha, there is an additional error in the log:

Trac[main] WARNING: 500 Internal Error (No handler matched request to /captcha .)

Really looks like there are wrong references - and that should read "/downloader/captcha" as well?

[anonymous]

The path with /download is correct, redirected link to file should look like

http://localhost:8080/trac104/test/downloader/download/file/9/my_program_0.1.exe

and unredirected link to file should be like

http://localhost:8080/trac104/test/downloader/download/file/9

You should check in your environment conf/trac.ini if there is correctly set "base_url" in section [trac]. For sure send your trac.ini too.

Replying to izzy:

P.P.S.: When I enable the captcha, there is an additional error in the log:

Trac[main] WARNING: 500 Internal Error (No handler matched request to /captcha .)

Really looks like there are wrong references - and that should read "/downloader/captcha" as well?

[izzy]

Replying to anonymous:

The path with /download is correct, redirected link to file should look like

http://localhost:8080/trac104/test/downloader/download/file/9/my_program_0.1.exe

That would mean "/downloader/download", not "/download" - and is exactly what I say.

and unredirected link to file should be like

http://localhost:8080/trac104/test/downloader/download/file/9

Yes, it does. But immediately after the download, it redirects to $base_url/download instead of either doing nothing or redirect to $base_url/downloader/download

You should check in your environment conf/trac.ini if there is correctly set "base_url" in section [trac]. For sure send your trac.ini too.

It is left empty (auto-detect), which works fine for everything else. For testing, I set it - but the results are the same:

WARNING: 500 Internal Error (No handler matched request to /download .)

immediately after the download was processed.

So I checked a bit in the source: _serve_file returns None on a successful download. It is called from process_request in web_ui.py - and there, following the download, this value is intepreted. Now see line 132 in that file:

        if output == None:
            raise TracError, "No handler matched request to /%s ." % self.arg_1

Well, no wonder, huh? On every successful download, this error is raised (at least if I understand that right - but I'm not that familiar with Python).

[izzy]

P.S.: Just to verify, I commented out line 132 + 133 (as quoted above). Guess what? Download works fine! PDF stays intact and is displayed in Evince.

But since I do not know what implications this may have (the exception handler is certainly not there just for fun), I hope you have a better solution ;) I tried to change the return value after a successful download - but I don't know to what I can change it ("True" does not work since a sequence is expected; changing the condition to return None if the request failed also does not work). Guess I better leave the real fix to you ;)

[anonymous]

Yes, it seems you found a bug, but the question is why is this problem only on your server. :o) I'm working on correct solution but yes, removing that lines is partially correct but not completely... Wait few minutes, I'll attach here changed web_ui.py file...

Replying to izzy:

P.S.: Just to verify, I commented out line 132 + 133 (as quoted above). Guess what? Download works fine! PDF stays intact and is displayed in Evince.

But since I do not know what implications this may have (the exception handler is certainly not there just for fun), I hope you have a better solution ;) I tried to change the return value after a successful download - but I don't know to what I can change it ("True" does not work since a sequence is expected; changing the condition to return None if the request failed also does not work). Guess I better leave the real fix to you ;)

[izzy]

Replying to anonymous:

Yes, it seems you found a bug, but the question is why is this problem only on your server. :o)

Murphy's law - it's always me...

I'm working on correct solution but yes, removing that lines is partially correct but not completely...

I did that just to isolate the issue and to see whether I identified the problem. I'm aware it is not the "final solution" ;)

Wait few minutes, I'll attach here changed web_ui.py file...

Sure! As soon as I got that, I will immediately test and report back. As soon as I'm back from lunch... ;)

[Petr Škoda]

Test patch for error after downloadig file problem.

[Petr Škoda]

Ok, I've attached modified model.py file (finally it's not web_ui.py), please try it and tell me.

Replying to izzy:

Replying to anonymous:

Yes, it seems you found a bug, but the question is why is this problem only on your server. :o)

Murphy's law - it's always me...

I'm working on correct solution but yes, removing that lines is partially correct but not completely...

I did that just to isolate the issue and to see whether I identified the problem. I'm aware it is not the "final solution" ;)

Wait few minutes, I'll attach here changed web_ui.py file...

Sure! As soon as I got that, I will immediately test and report back. As soon as I'm back from lunch... ;)

[izzy]

Yeah! Looks great. I replaced that file in the eggs directory, and made my previous changes undone (commenting out those two lines). Just to be sure, I reloaded the apache. Clicked on the PDF then, which opened fine in Evince. Guess that fixes it - THANX!

[Petr Škoda]

Thank you for your help. I've uploaded changes into SVN.

Replying to izzy:

Yeah! Looks great. I replaced that file in the eggs directory, and made my previous changes undone (commenting out those two lines). Just to be sure, I reloaded the apache. Clicked on the PDF then, which opened fine in Evince. Guess that fixes it - THANX!

[izzy]

I thank you for the fast solution!