You must not rely on browsers respecting the content-type
header for security. A quick look at CVE-2010-1420 should give you an idea. Content-sniffing mechanism implemented in browsers can be manipulated by attackers to trigger XSS attacks (Secure Content Sniffing For Web Browsers: A Survey).
Survey of content sniffing behaviors

According to this survey, as you may see, Safari browser could cause a problem even this is not an issue in other browsers (I can add you Bug 637981 to this list).
Go further:
You can protect further your application by allowing your web server to force the browser into disabling MIME Sniffing for the served file:
X-Content-Type-Options: nosniff
Since the attacks you are trying to defend against could be done via the files that you may allow today or tomorrow your visitors to upload, you can force the browser to present the user with a file save dialog. When the noopen
header is set, the user can not open the file directly because he will be forced to save the file locally first, which prevents the file from being rendered in the current browser context. You can achieve that by:
Content-Disposition: attachment; filename=untrustedfile.html
Additionally, in this last case (I mean if you allow users to upload files), you can add an other security layer to your web application (Risky sniffing):
- Use a whitelist to ensure that only a limited amount of file extensions are allowed
- Store uploaded files outside the web root and use a secure download script that loads these files from disk and presents their contents to the user;
- Use non-predictable filenames and change the file extension.