Opened 9 years ago

Closed 9 years ago

## #2676 closed defect (fixed)

### Description

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

### comment:1 in reply to: ↑ description ; follow-up: ↓ 2 Changed 9 years ago by peca

• Status changed from new to assigned

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.

Thanks.

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

### comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 9 years ago by izzy

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

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.

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.

### comment:3 in reply to: ↑ 2 Changed 9 years ago by peca

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

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

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.

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.

### comment:4 Changed 9 years ago by 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).

### comment:5 Changed 9 years ago by 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".

### comment:7 follow-up: ↓ 8 Changed 9 years ago by 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 .)


### comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 9 years ago by anonymous

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.

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


### comment:9 in reply to: ↑ 8 Changed 9 years ago by izzy

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


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:

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

### comment:10 follow-up: ↓ 11 Changed 9 years ago by 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 ;)

### comment:11 in reply to: ↑ 10 ; follow-up: ↓ 12 Changed 9 years ago by 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...

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

### comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 9 years ago by izzy

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

### comment:13 in reply to: ↑ 12 Changed 9 years ago by peca

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

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

### comment:14 follow-up: ↓ 15 Changed 9 years ago by 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!

### comment:15 in reply to: ↑ 14 Changed 9 years ago by peca

• Resolution set to fixed
• Status changed from assigned to closed

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!

### comment:16 Changed 9 years ago by izzy

I thank you for the fast solution!