"Download in other formats: Plain Text" link at the bottom of this site wiki pages does not work in Firefox 7.0.1

[bdimych@…]

and in SeaMonkey 2.4.1 too

the error message is "Corrupted Content Error"

[Remy Blank]

Can you please try one of the other major browsers (IE, Opera, Chrome, Safari)?

I have found this:

• ​https://bugzilla.mozilla.org/show_bug.cgi?id=681140 — "… this error occurs when the server response has multiple, conflicting values for the Content-Length, Content-Disposition, and/or Location headers."

It's even in the release notes:

Firefox will now display a corrupted content error when it detects certain types of misconfigured servers. This is not a Firefox issue, please contact the website owner (see bug 681140).

So I guess we'll need to look through our headers.

[Remy Blank]

And indeed, we are sending duplicate headers:

$ wget -S "http://trac.edgewall.org/wiki/WikiStart?format=txt"
--2011-10-15 09:18:30--  http://trac.edgewall.org/wiki/WikiStart?format=txt
Resolving trac.edgewall.org (trac.edgewall.org)... 78.47.205.98
Connecting to trac.edgewall.org (trac.edgewall.org)|78.47.205.98|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.0 200 OK
  Connection: keep-alive
  Content-Disposition: attachment; x=y
  Content-Disposition: filename=WikiStart.txt
  Content-Type: text/plain;charset=utf-8
  Content-Length: 4949
  Set-Cookie: trac_session=96eb54ece2c7b1245c5141cb; expires=Fri, 13-Jan-2012 07:18:30 GMT; Path=/
  Date: Sat, 15 Oct 2011 07:18:30 GMT
  Server: lighttpd/1.4.19
Length: 4949 (4,8K) [text/plain]
Saving to: “WikiStart?format=txt”

100%[======================================>] 4.949       --.-K/s   in 0,03s   

2011-10-15 09:18:30 (155 KB/s) - “WikiStart?format=txt” saved [4949/4949]

The "x=y" looks weird.

[Christian Boos]

Indeed, some weird workaround for some version of Safari: r5274. That was 4 years ago, probably not worth keeping any longer.

That x=y itself probably came at some point from ​http://greenbytes.de/tech/tc2231/#attmissingdisposition2 …

[Remy Blank]

The issue should be fixed with [10832]. That changeset also fixes all Content-Disposition headers with a filename to use content_disposition() to ensure proper escaping.

There is a small behavior change, though: now, the "download as plain text" link will display the text in the browser, instead of forcing a download. The user can still save the text with "Save Page as…". I could restore the previous behavior, but I'm not sure we want that. For comparison, we don't force a download for any of the other conversions (CSV, TSV, SQL), it just so happens that the file extension triggers the download (at least in Firefox).

So, should I force the download?

[Remy Blank]

Bah, probably not. Let's close this.

[Jun Omae]

Sorry about my reply to a year old ticket.

Replying to rblank:

So, should I force the download?

Yes, we should force at least Internet Explorer to download.

The reason is the same as…

• Always send "Content-Disposition: attachment" headers where potentially unsafe (user provided) content is available for download. This behaviour can be altered using the "render_unsafe_content" option in the "attachment" and "browser" sections of trac.ini.
• Fixed XSS vulnerability in "download wiki page as text" in combination with Microsoft IE.

from changelog for Trac 0.10.3.1​.

[eb858f7c/jomae.git].

[Remy Blank]

Too bad, I actually liked the possibility to view text files in the browser. Oh well…

Looks good, please apply!

[Jun Omae]

Ok. Applied in [11233] and merged in [11234].

[miked@…]

Sorry if this is unrelated but Seamonkey 2.4.1?

At ​http://www.seamonkey-project.org/ the latest version is 2.12.1, but I found this page from Nov. 2011: ​http://www.seamonkey-project.org/releases/seamonkey2.4/

Can someone explain that to me?