Attachments Fooling Browsers

[anonymous]

I am using 0.9.4 and it appears there is a problem with some browsers and attachments. When you click on an attachment like a pdf, it first presents an html page to let you know you should download the following link.

The problem is that this html page ends with the name of the attachment and not-so-bright systems sometimes interpret this as the filetype indicator hence, a .pdf will be handed to a pdf viewer.

O.K. some systems are not so bright, but I think it wouldn't be hard to alter trac so that any page that is definitely html ends with .html

[cmlenz]

What kind of “not-so-bright” system are you talking about here?

[Corley.Kinnane@…]

Someone using Firefox on a Windows machine - details later - probably using the suffix to determine mime-type.

If the html for presenting a download of a binary ended in .html or .htm then it could never happen.

[eblot]

I confirm this is a real issue with Firefox - and extensions such as PDF Download.

The trouble is that the link is presented as a .PDF file, whereas the link points on an HTML page. Several web clients expect a .PDF file, but do receive text/html data stream. Many web clients therefore save the received HTML content inside a .PDF file with the name of the original attached file. wget does...

[cboos]

Here's a possible fix for the issue, which is based on r3288: attachment:pdfattachment.patch

I verified that it works well for viewing PDF files using Firefox, while the PDF Download extension was active.

[cboos]

Possible fix for the issue, patch on source:trunk@3288 (take 2)

[cboos]

... and I just realized that the same problem exists for .pdf files in the repository. Maybe the same kind of fix can be done for the TracBrowser.

[cboos]

Similar patch, this time for the TracBrowser.

[cboos]

In attachement:browser_html_txt.patch, I think I also solved the issue for the TracBrowser.

The principle is similar:

• adding the .html suffix when rendering a preview for a file in the repository
• adding the .txt suffix when sending it plaintext; note that this should also be done for attachments, in the first patch.
• adding nothing when viewing the raw file.

Also note that I didn't do the required change besides from the browser.py file, so it's certainly the case that there are other browser links that will need to be modified.

Now, in order to generalize the addition of a suffix in everycase but the raw format, I think we need to consider that when we generalize #2296 to attachments and to the source browser, perhaps by using the key argument as the suffix (and rename key to format or extension?).

[cboos]

I'd like to get some feedback on this one: what I implemented in attachment:browser_html_txt.patch actually solves the issue, but I'm not very fond of the solution. In particular, I don't like the fact that the URLs are not intuitive anymore.

I'm not sure if there's another approach that could be tried to solve this, so at that point I'd rather advice to disable the PDF Download extension and to leave things as they are (i.e. wontfix).

[cboos]

combined and updated patch (i.e. the approach pushed to the extreme :) )

[cboos]

Reiterating what I said above, I'd rather advice to disable the PDF Download extension and to leave things as they are.

[cboos]

r4242 implemented something like attachment:browser_html_txt.patch, but in a cleaner way.

I'll do something similar for attachments.

[cboos]

Done in r4246.

[cboos]

Oops, re-reading the original description of this ticket, it seems that r4246 probably won't help with the original problem. I mistakenly thought this ticket was the same as #3083 but for attachments...

[cboos]

... so I'm restoring this one to its original resolution!