Bad handling of URLs in IE5/6 when downloading files in raw format

[Christophe.Muller@…]

Hello,

The problem really lies in Internet Explorer I think and not trac but the fact that the URL for original format links would be of the form "…/file.exe?format=raw" (or any other binary type) makes IE want to save a file called "file" without the extension, and thus… that cannot be ran afterwards. It also happens for example when the URL is "…/file.tgz?format=raw" in which case IE renames it to "file.tar"!???! I have tried to look for solutions on the web but could only find people with the same problem. One of the suggestions, though, was to add to the HTTP header a Content-Disposition field which forces 1) a download and 2) a filename (this HTTP feature is described in RFC 1806).

I have patched my own working copy of trac with the following code (file versioncontrol/web_ui/browser.py) in _render_file:

format = req.args.get('format')
if format in ['raw', 'txt']:
    req.send_response(200)
    if format == 'raw':
        filename=node.path.split('/').pop()
        req.send_header('Content-Disposition', 'attachment;' + 'filename=' + filename)
    req.send_header('Content-Type',
                    format == 'txt' and 'text/plain' or mime_type)
    req.send_header('Content-Length', node.content_length)
...

And it seems to do the trick for IE: when clicking on raw versions, IE now proposes to save the file with exactly the file name that we send in the HTTP header.

I'm not sure you will want to fix IE bugs with workarounds :-) but just in case, I fill this ticket. Thanks for the attention.

Cheers,

Christophe.

= Ubuntu is an ancient African word, meaning "I can't configure Slackware". =

[schuetze@…]

The same problem exists for attachments in the wiki (see attachment.py). There is a HTTP-header 'Content-Disposition', but only for not-binary - why? Binaries should have this header also.

[Christophe.Muller@…]

Patch. It seems my bug is still new five month later… :-(

[Christian Boos]

Sorry, the patch/issue probably got unnoticed.

Also, #3332 supersedes this one, for 0.11dev.

We could probably put that in 0.10.1, though. Any objections?

[Christophe.Muller@…]

Replying to cboos:

Sorry, the patch/issue probably got unnoticed.

No problem. I understand that can happen (and I have my patch installed already.. :-).

Thanks for picking it up.
Cheers,
Christophe

 = The game's isn't over until it's over.  --Yogi Berra =

[Christian Boos]

Oops, just tested this further, and the proposed patch actually enforces a download of the page, which prevents the document to be viewed directly in the browser, which is often desirable for e.g. viewing HTML documentation stored in the repository.

So the correct solution for this issue seems to be to get rid of the ?format=raw. This can be achieved using the patch I proposed a few time ago on the ML, which proposed a /source/ access besides /browser/ (and also a raw-source: TracLinks resolver for this; admittedly source: would be better, but it's already widely used as an alias to browser:).

See attachment:raw-source-r4039.diff​

[Christian Boos]

Add direct raw access to files in the repository

[Christian Boos]

Also, as noted in #3579, the first "path" element should be mandatory and interpreted as a revision number.

Instead of /source for the URL and raw-source: for the link resolver, the idea is now to use /export and export:.

The question is open whether we'd support something similar for attachments (e.g. /raw-attachment/wiki/page/document.pdf, revival of #2974 only for attachments).

[Christian Boos]

Implemented in r4242.

The Original Format alternate download link now use this new export URL.

[Christian Boos]

In r4246, the same approach was used for the attachments (raw-attachment: link resolver in the Wiki and /raw-attachment URL prefix).