Edgewall Software
Modify

Opened 14 years ago

Closed 13 years ago

#2974 closed defect (wontfix)

Attachments Fooling Browsers

Reported by: anonymous Owned by: Christian Boos
Priority: normal Milestone:
Component: general Version: 0.9.4
Severity: normal Keywords: attachment file preview
Cc: Branch:
Release Notes:
API Changes:

Description

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

Attachments (3)

pdfattachment.patch (3.2 KB ) - added by Christian Boos 13 years ago.
Possible fix for the issue, patch on source:trunk@3288 (take 2)
browser_html_txt.patch (5.6 KB ) - added by Christian Boos 13 years ago.
Similar patch, this time for the TracBrowser.
pdf_attachment_browser.diff (19.7 KB ) - added by Christian Boos 13 years ago.
combined and updated patch (i.e. the approach pushed to the extreme :) )

Download all attachments as: .zip

Change History (16)

comment:1 by Christopher Lenz, 14 years ago

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

comment:2 by Corley.Kinnane@…, 14 years ago

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.

comment:3 by Emmanuel Blot, 14 years ago

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…

comment:4 by Christian Boos, 13 years ago

Milestone: 0.10
Owner: changed from Jonas Borgström to Christian Boos
Status: newassigned

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.

by Christian Boos, 13 years ago

Attachment: pdfattachment.patch added

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

comment:5 by Christian Boos, 13 years ago

Keywords: attachment file preview added; Attachment Extension removed

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

by Christian Boos, 13 years ago

Attachment: browser_html_txt.patch added

Similar patch, this time for the TracBrowser.

comment:6 by Christian Boos, 13 years ago

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

comment:7 by Christian Boos, 13 years ago

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

by Christian Boos, 13 years ago

Attachment: pdf_attachment_browser.diff added

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

comment:8 by Christian Boos, 13 years ago

Milestone: 0.10

comment:9 by Christian Boos, 13 years ago

Resolution: wontfix
Status: assignedclosed

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

comment:10 by Christian Boos, 13 years ago

Milestone: 0.11
Resolution: wontfix
Status: closedreopened

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

I'll do something similar for attachments.

comment:11 by Christian Boos, 13 years ago

Resolution: fixed
Status: reopenedclosed

Done in r4246.

comment:12 by Christian Boos, 13 years ago

Resolution: fixed
Status: closedreopened

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…

comment:13 by Christian Boos, 13 years ago

Milestone: 0.11
Resolution: wontfix
Status: reopenedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.