Internet Explorer 6/7 shows "Unknown File Type"

[Ross]

Dear Trac Developers,

Sorry for posting it like a ticket for Trac, though its actually a ticket for installation problem with my configuration:

Internet Explorer 6/7 shows "Unknown File Type" when you click on links like "Unified Diff" and "Zip Archive" in Browser or Changeset and loads a file without extension. So you have to add .zip or .diff file extension manually. Firefox and Opera work ok.

I guess the problem is with my Apache 2.2 installation. Checked httpd.conf - mime types are set correctly, application\zip → .zip and so on.

Could you point what may be wrong?

[Christian Boos]

Right, that's an annoying problem with IE, I don't think it's a misconfiguration on your part (anyway, it should work out of the box).

I think adding an explicit .diff and .zip extension where needed is doable.

[osimons]

I think this is closely related to #5557 - bordering on duplicate?

[Christian Boos]

No, not really.

Looking at the code, it seems we already use filename for diffs and zips.

  req.send_header('Content-Disposition',
                  content_disposition('inline;', filename + '.diff'))

But IExplorer happily discards the info. Using 'attachment' disposition doesn't fix it. I think the only change that could possibly convince IExplorer to do right thing would be to redirect to /changeset/xxxx.diff or /changeset/xxxx.zip.

See attachment:explict_extension_for_changesets-r6501.diff​. With that change, both the diff files and the zip files are opened appropriately when using IE (FF and Opera are still doing fine).

(Now speaking of #5557, feel free to re-schedule it, as you saw some improvement by using the patch you proposed there - but AFAICT that ticket was more about the extension for attached files dissapearing, whereas here there were no such extensions before the patch added them).

[Christian Boos]

Workaround an IExplorer limitation - it's only when .diff or .zip is in the URL that IE will propose to do the appropriate action on the downloaded file

[osimons]

Tested attachment:explict_extension_for_changesets-r6501.diff​, and that sure seems to work better. +1 on such a workaround as it is quite an annoying issue.

Only remaining thing I can see is that the naming of the file is wrong. Instead of the FF behaviour of changeset_r125.diff naming, the filename looks to be a temporary filename - actually, just clicking the link and then 'Cancel' suggests a new name each time.

[osimons]

Tested using downloadable paths as well, and that shows same behavior: Not solved by patch, so I suppose there is another location in the code that needs the treatment.

Typically downloading /trunk as .zip, will just request to save trunk in IE.

[Christian Boos]

Please have a look at the newer patch (attachment:explict_extension_for_changesets-r6502.diff​), which should take care of the downloadable paths as well.

[Christian Boos]

Force IExplorer to do the right thing with alternate downloads in changeset module

[osimons]

Replying to cboos:

Please have a look at the newer patch (attachment:explict_extension_for_changesets-r6502.diff​), which should take care of the downloadable paths as well.

Yup. The dialogue and download is working well. Correct file types.

As for using 'file.zip' or 'file.diff' for all such IE downloads, I suppose it is as good as it gets. Making it more explicit can lead to confusion as the patch don't actually use the filename as a relevant part of the path - only stripping it off. It makes for nicer links, but more hassle at the receiving IE end when all files still needs to be renamed to be descriptive.

[Christian Boos]

Apparently, the only way to avoid the need for renaming would be to prepare the full name in the link (doable), and set what has to be stripped as an extra parameter.

e.g.

/changeset/changeset_r321.diff?format=diff&rev=321&strip=changeset_r321.diff

I'm not sure. The link sure looks ugly but it's not really meant to be seen nor used directly. The benefits seem to outweight the disadvantages though.

[anonymous]

Thanks, I wil test the patches. For some unknown reason for me on your site

​http://trac.edgewall.org/browser/trunk

the "Download Zip" links worked correct with IE even before I created the ticket. Did you already use some top-secret patches and made them public only now? :)

[anonymous]

I tested r6502.diff and it is working as you explained above.

Only problem is that name of file in IE is always "file.zip", not path-rXXX.zip.

But could anyone explain me WHY here ​http://trac.edgewall.org/browser/trunk everything is working fantastic with IE (and the filename is correct). Is this some new version of Apache or some new fix mwe are not aware of?

[Jeroen Ruigrok van der Werven]

t.e.o. still uses 0.10.4. It would be interesting to see if a 0.10.4 does it correctly.

[osimons]

It is related to #5557 and the change on trunk in [4351] not present for 0.10-stable.

Here is a diff that I think solves it:

trac/util/__init__.py

@@ -468 +468 @@
 
 def content_disposition(type, filename=None):
     """Generate a properly escaped Content-Disposition header"""
-    from email.Utils import encode_rfc2231
     if isinstance(filename, unicode):
         filename = filename.encode('utf-8')
-    return type +'; filename*=' + encode_rfc2231(filename, 'utf-8')
+    return type + '; filename=' + quote(filename, safe='')
 
 def pairwise(iterable):
     "s -> (s0,s1), (s1,s2), (s2, s3), ..."

encode_rfc2231('trunk.zip', 'utf-8') returns a funny-looking string like "utf-8''trunk.zip". No browser handles this string in any meaningful manner. This has never really been noticeable due to what surely must be a spelling mistake - filename*= instead of filename=. Quoting without safe characters returns the same result for international characters, so the patch just uses that.

Related again to #5557, what happens now:

• Correct 'save as…' display for all regular ascii filenames on all major platforms.
• Any international characters in filename will be quoted:
  • IE will actually unquote it automatically when 'utf-8' so that looks great.
  • Mozilla does not unquote, and will save a quoted filename.

Patch makes it perfect for IE, and worse for Mozilla and Safari now that the header actually gets recognized overriding their built-in auto-detection of the filename. Without browser detection in code, I don't think there is any ideal way to do this - basically do conditional include of the filename= attribute if we don't consider quoting an OK solution.

[anonymous]

The original bug description says "Checked httpd.conf - mime types are set correctly, application\zip → .zip and so on."

Note that the separator "application\zip" is a backslash. Is that a typo? It should be a forward slash "application/zip"

References:

• ​http://www.w3schools.com/media/media_mimeref.asp
• ​http://www.rfc-editor.org/rfc/rfc2046.txt

[osimons]

Replying to anonymous:

The original bug description says "Checked httpd.conf - mime types are set correctly, application\zip → .zip and so on." Note that the separator "application\zip" is a backslash. Is that a typo? It should be a forward slash "application/zip"

Nope. The problem is not with the web server setup. The problem is confirmed by many and researched by several devs, and we do have a problem of finding the best way to present and handle downloads so that all browsers treat them in a user-friendly manner.

[anonymous]

Guys you need to look into security? I was able to close this issue without having to login to the system…

I'm not sure it's right behavior of the system

Regards, Alexey

[osimons]

Replying to anonymous:

Guys you need to look into security? I was able to close this issue without having to login to the system…

I'm not sure it's right behavior of the system

Well, it is correct behaviour. And, no doubt you could have figured that out by looking around instead.

This site contains contributions and involvement from a large number of people, and only a fraction of them (developers) have logins. With the exceptions of spam, test tickets and test edits, and people proving points (like you), this open policy is a very positive aspect of the project. All changes are tracked by a large number of people helping out, and wrong or malicious changes would not stay that way for long. However, we would all rather spend our time doing other things than undoing stupid changes.

Regards, Alexey

Alexey, you are empowered. Please use it for contributions that actually bring value to others.

[Christian Boos]

Replying to osimons:

It is related to #5557 and the change on trunk in [4351] not present for 0.10-stable.

Here is a diff that I think solves it:

I tried that patch.

• Any international characters in filename will be quoted:
  • IE will actually unquote it automatically when 'utf-8' so that looks great.
  • Mozilla does not unquote, and will save a quoted filename.

I don't know if you were talking about "Mozilla" or Firefox, but for me, FF 2.0.0.14 on Windows does the right thing.

That was with tracd on the server side, so no httpd.conf - mime types involved here.

I also tested with Safari 3.1.1, Opera 9.27 and IE 7, all are working fine with the changesets diffs and .zip files.

Patch makes it perfect for IE, and worse for Mozilla and Safari now that the header actually gets recognized overriding their built-in auto-detection of the filename. Without browser detection in code, I don't think there is any ideal way to do this - basically do conditional include of the filename= attribute if we don't consider quoting an OK solution.

I also checked that downloading attachments or files from the repository (with non-ascii characters) is still working as expected using all of the above browsers, so there seems to be no regression on #5557.

I think this looks good for rc1.

[Christian Boos]

Fix from osimons in comment:12 committed as r6935.

I also tried on Linux with an old Konqueror browser (3.2.1). With this browser, the diff and zip download were also not working, but the above fix did the trick for that browser as well.