Description

The new macro syntax activates the ugliest feature of IE called "MIME sniffing", when requesting Raw Text.

IE sees "<...>" and thinks it's actually text/html, not text/plain, and shows crap.

Steps to reproduce

Just see the Raw Text of this page.

Example

Component selection

• general

Details

Workaround

• Use a non-broken browser, if possible.
• Use edit action to look at raw text. Don't forget to cancel editing after looking.

• Make a special "ShowSource" plugin action that can be used by IE users (using text/html and wrapping the raw content into <pre>).

• alternatively rename TableOfContents.py to TOC.py and use <<TOC>>. But I guess it would still happen with e.g. <<BR>> if it is used near the top of the page (or any other wiki macro with a name starting like some html tag).

Annotation: You can also use the save-action to download/save the raw-text-file on your local disk. Opening this text-file with IE7 works surprisingly fine (whereas raw-action causes trouble as described above).

• Thanks for testing this, I think the reason is the .txt extension. Could it be that IE does always guess the mimetype and do ignore the content type if there is no extension given? -- ReimarBauer 2008-05-30 14:02:47

  • I have now deleted the txt extension so that the file is an unknown filetype for windows (I also made sure that I have no caching problem). Result: Opening of the unknown file-type worked fine! No crap. The raw text is correctly displayed. I tested this with several other pages. Always the same. It works fine. But that's also a kind of strange why it doesn't work if you use action=raw.. -- OliverSiemoneit 2008-05-30 15:29:31

It is also possible in IE 7 to go into the security options for the appropriate zone (such as local intranet) and change the setting for "Open files based on content, not file extension" to disable. This page then renders correctly, but there is a yellow information bar warning saying that the content does not match its security information. Supposedly the "Open files based on content, not file extension" was added at IE 6 SP 2. It seems possible that for intranet based Wikis that the system administrator could force this change across the domain. -- JohnCarlson 2008-05-30 23:27:15

Alternatively one can modify the settings IExplore.exe and/or Explorer.exe in the registry under

HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\\FeatureControl\FEATURE_MIME_SNIFFING\

and/or

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_MIME_SNIFFING\

to 0 (null) in order to disable "MIME sniffing". Source: http://technet.microsoft.com/en-us/library/cc787872.aspx.

Discussion

This is definitely a IE bug (or rather a really bad "feature" - they should not try to make wild guesses if they already know the right content-type).

IE just ignores the correct Content-Type when it sees e.g. <Table (as in <<TableOfContents>>).

Moin emits a valid content-type header of text/plain, IE should not ignore this and try to make wild guesses.

• For a normal wiki page moin returns something like: Content-Type: text/html; charset=utf-8
• For a raw text moins return: Content-Type: text/plain; charset=utf-8

Thus, we won't try to work around this problem in moin. If you like to implement some of the workarounds mentioned above and you need help, feel free to ask on #moin or here.

Plan

• Priority:
• Assigned to:
• Status: no moin bug, IE severely broken

CategoryMoinMoinNoBug