<<TableOfContents>> 

= 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 ==
## Describe the steps needed to reproduce the bug. If we can't reproduce it, we  probably can't fix it.
Just see the Raw Text of this page.

== Example ==
##Add URL that show the bug, screenshot or test wiki markup that fail...


##URL: 

##attachment:screenshot.png

##{{{
##Example wiki markup that fail
##}}}

== Component selection ==

## Where you think is this bug happening ? (general, plugin [plugin name], theme [theme name], ...

 * general

== Details ==

## If you got a traceback, please save the traceback page as html and attach here:
## attachment:traceback.html

## if the bug is in this wiki, just kill the table and write: This Wiki.

## If a traceback is not available, please fill in the details here:
|| '''!MoinMoin Version''' || 1.6.x ||
|| '''OS''' || WinXP SP2 ||
|| '''IE version''' || 6.0 SP2, 7.0 ||

== 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 <<DateTime(2008-05-30T16:02:47+0200)>>
  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 <<DateTime(2008-05-30T16:29:31+0100)>> 

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 <<DateTime(2008-05-30T17:27:15-0600)>>

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 =
## This part is for Moin``Moin developers:

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

----
## If you are a moin core developer, replace the category to Category* in these cases:
## Category MoinMoinNoBug - if this is not a bug.
## Category MoinMoinBugConfirmed - if you can confirm the bug on current code.
## Category MoinMoinBugFixed - after the bug is fixed in current code.
CategoryMoinMoinNoBug