Downloading attachments in rc2

[ASeques]

I don't know if it's supposed to work this way, but there is a paperclip at the side of the attachments. In my opinion the approach should be (maybe already is that and has some failures):

• The paperclip should be a direct way to download the documents.
• Clicking on the name could do the preview that's doing now.

Reasons:

• People sometimes just want to download a .pdf or an image without viewing it.
• Preview images has some issues with css in some navigators

[thomasb]

The paper clip is just a style element but people can download the attachment by right-clicking on the name and then choose "save as".

[ASeques]

It doesn't work that way, at least in rc2 and with pdf.
The name link points to: ​https://webmail.example.com/round/?_task=mail&_action=get&_mbox=INBOX&_uid=7398&_part=1
And if I click at that link (attachment was test.pdf) , it wants to save test.pdf.htm

I can open that with acroread and is the right file, but it should be saved with appropiate filename no so we don't have to tell people to associate their .htm or to be opened with acrobat reader.

[thomasb]

Well, it works for me. What browser do you use?

[ASeques]

Hi, there are two different cases:

1.- Mail sent from thunderbird with the same pdf attached:

Content-Type: multipart/mixed;
 boundary="------------040208040304060905010104"

This is a multi-part message in MIME format.
--------------040208040304060905010104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

2.- Mail sent from within roundcube with a pdf attached.

Content-Type: multipart/mixed;
	boundary="=_80f2fbaf051bcbf77a7b60d97714871d"

--=_80f2fbaf051bcbf77a7b60d97714871d
Content-Transfer-Encoding: base64
Content-Type: application/pdf; name="781.pdf"; charset="UTF-8"
Content-Disposition: attachment; filename="781.pdf"

In the first case clicking on the name opens a download menu to get the file named "781.pdf"
In the second case opens a new windows that loads the acrobat reader (if available) and:

1.- In ie6, ie7 there is a very small frame to preview the pdf
2.- In firefox if you have the acrobat plugin it opens in a window with the proper size and you can save within the acrobat.

The problem in both cases where the attachment is sent with roundcube is that if you want just to download the attachent doing "save link as ..." downloads the file "781.pdf.htm" and the system does not associate with acrobat.

Hope I made myself clear this time :P, sorry to keep reopening the ticket

[seansan]

Continue in 0.1.1

[thomasb]

#1484770 marked as duplicate of this bug

[thomasb]

The problem with the small preview box is solved in 0.2-beta.

The reason why some browsers save the file as .htm when choosing "save as..." is that they just ignore the filename headers RoundCube sends. To only solution I can imagine would be to create URLs like ​http://mywebmail.net/781.pdf?_action=get&_mbox=INBOX&_uid=7398&_part=1 but this requires support by the web server like mod_rewrite. This would get along with #1484357

[tensor]

Something like path info may be used. It may even not require special server configuration.

http://mywebmail.net/attachment.php/781.pdf?_action=get&_mbox=INBOX&_uid=7398&_part=1

Adding a small download icon near every file to forcibly download with application/octet-stream would solve the issue.

Consider for 0.2?

[alec]

This "path info hack" works for me with Apache. How about IIS and others?

[alec]

Attached patch fixes this. However I see it's not needed on IE7, so do we really still need this?

[alec]

I'm closing this long standing bug. I've tested this with IE7/8 and those browsers doesn't need it. So, is there any browser that need this?