Tags:
create new tag
view all tags

Question

  • We added some visio files as attachments to some topics.
  • If you click the link to the attachment firefox tries to open the visio file instead of providing a download menu.
  • It works fine with Internet Explorer 6.0.
  • Thanks for your help.

Environment

TWiki version: TWikiRelease04x01x02
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: RedHat Linux
Web server: Apache
Perl version: 5.8
Client OS: Windows XP Service Pack2
Web Browser: Firefox
Categories: Browser Issue

-- KirstinWeber - 11 Sep 2007

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

My guess is that your Visio file is served with a content type text/plain. There is a sequence of steps which determines what a browser does with a certain URL. Errors can occur in some of them, so let's walk through them to see whether the problem can be tracked down.

  1. You upload a Visio file with a certain extension which your client system associates with Visio - typically one of .vsd, .vst, .vsw.
  2. TWiki most probably stores the file under the name you provided. Please check: Does it have an additional .txt extension?
    • If so (very unlikely): There is a configuration setting {UploadFilter} (you need to enable the EXPERT options to see it, it is in the section Security/Miscellaneous) which defines a regular expression for "dangerous" extensions, these are enforced to be displayed as text files by appending .txt to the file name. Per default it should not touch Visio files. See TWiki04x01.FileAttachment for more information.
  3. You click on the link.
  4. The web server provides the file, and supplies a Content-type header. Unless specified otherwise (unlikely), the content type is determined based on the file extension. There are two possibilities:
    1. You clicked on a bin/viewfile type of link (e.g. in the attachment table). In this case TWiki determines the content type based on the mappings defined in a file configurable as {MimeTypesFileName} (EXPERT setting under Miscellaneous). Default is something like data/mime.types.
    2. You clicked on a pub type of link (as created by the %ATTACHURL% variable). In this case, TWiki is not involved, the mapping is done directly by Apache based on the mappings in (usually) /etc/mime.types.
    • So check whether the mime.types file contains an entry for the extension of your Visio file. Per default, current versions of both TWiki and Apache ship with a mapping of .vsd to application/vnd.visio but lack definitions for other Visio extension. In that case, both TWiki and Apache will usually serve the file as text/plain.
  5. Finally, the browser software decides what to do with a given content type. Again, there are two cases, accounting for the difference you observe:
    1. Internet Explorer overrides the content type with its own guess what should be done with the file. That's why I guess it works in your case: IE "hides" an error in the server configuration for you (there are cases where this extra intelligence of IE causes extra problems).
    2. Firefox respects the content type provided by the server, and consults the Windows registry about how to proceed with that content type. It is unlikely that this is misconfigured, and unfortunately I have no windows system at hand and do not recall where to find the Windows mapping :-/

If you find that the error is related to a missing or incomplete entry in one (or both) of the mime.types files, I'd suggest you add the following line:

application/vnd.visio                           vsd vst vsw vss
This defines all extensions which are registered at IANA for Visio (http://www.iana.org/assignments/media-types/application/vnd.visio)

-- HaraldJoerg - 11 Sep 2007

  1. The type is .vsd.
  2. I do not see that .txt is added to .vsd in the attachment table.
  3. Result depends on where I click on the link.
    1. I get the download menu => everything is allright (.vsd is contained in the wiki mime type file).
    2. I get plain text.

So I draw the conclusion that .vsd is missing in the mime type file of the apache server and I have to look there. Right? Thanks for your help.

-- KirstinWeber - 12 Sep 2007

Yes, that's correct. RedHat seems to have a /etc/mime.types, but the file which is actually used by Apache is in its server configuration file: look for a TypesConfig directive in Apache's configuration files. Unfortunately I don't know where RedHat stores these, might be /etc/httpd/ or /etc/apache2/, and either httpd.conf or apache2.conf or something like that. Apache's native default is to use its own file relative to the server root conf/mime.types, but the packages in distributions normally override this and explicitly define a file name.

-- HaraldJoerg - 12 Sep 2007

Thanks for your help. Now I have to wait because I haven't the permissions to look into the configurations of the Apache and the administrator is on vacation. Afterwards I will add a comment if my problem is solved so other can use the same solution if it works.

-- KirstinWeber - 12 Sep 2007

Closing this after more than 30 days of inactivity. Please feel free to re-open if needed.

-- PeterThoeny - 01 Nov 2007

This might help others who found this thread as I did: I couldn't open Visio attachments in IE6. The mime types were configured properly.

It turns out that it was a bug in Visio 2003, which was fixed in SP 1 (in 2004). I installed Visio 2003 SP 3, and then the links worked:

-- SeanCMorgan - 28 Nov 2007

An administrator added the missing mime types and now it works.

-- KirstinWeber - 14 Jan 2008

Change status to:
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2008-01-14 - KirstinWeber
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.