css files not used if CSS stylesheet returns a MIME type other than text/css

RESOLVED DUPLICATE of bug 156145

Status

()

Core
CSS Parsing and Computation
RESOLVED DUPLICATE of bug 156145
16 years ago
15 years ago

People

(Reporter: Ben Elkin, Assigned: dbaron)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/4.5 (compatible; OmniWeb/4.1.1-v424.6; Mac_PowerPC)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126

Due to (mis)configuration of the web server, .css files were delivered without the proper MIME type (or even as binary files?). Mozilla didn't use the stylesheets then at all.

Reproducible: Always

Steps to Reproduce:
1. In Suffix Mapping configuration of WebSTAR 4.5 on MacOS 9.1 remove the .css item (if it was there)
2. clear both browser and server caches
3. view a page which uses an external stylesheet.css

Actual Results:  
The page displays wrong: as if the stylesheet.css were not there

Expected Results:  
proper display

The bug reproduces with Netscape 7 on MacOS X and WinNT, and with Mozilla 1, 1.1, and 1.2 on MacOS X. Our pages displayed properly with Netscape 4 and 6, IE, and other browsers. 

Unfortunately ;-) I have now fixed our server <http://www.igb.fhg.de> settings, so you can't reproduce the problem just by visiting our homepage. In an extreme case, I could reverse the server settings for a limited period od time (max 1 working day or 1 weekend) to help reproduce the problem.
Assuming the page in question has a standards-mode DOCTYPE, this is not a bug. 
See http://devedge.netscape.com/viewsource/2002/incorrect-mime-types/ for more
information.  ->INVALID
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
The whole purpose is to get you to fix your server.  The HTTP spec, RFC 2616,
Section 7.2.1 Paragraph 3 says:

   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URI used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

Note in particular, the second sentence.  Since you provided us with a
Content-Type, we were not permitted to guess at the actual type of the file and
treated it as whatever you sent it as, which as you stated, was not CSS.  Our
behavior in standards mode is correct.

VERIFIED INVALID.
Status: RESOLVED → VERIFIED

Comment 3

15 years ago
Reopening to mark as a dup of bug 156145 (also invalid).
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---

Comment 4

15 years ago

*** This bug has been marked as a duplicate of 156145 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 5

15 years ago
As noted in Bug 156145, if you can't get the server fixed, you may be able to
use an .htaccess to add the mime type yourself, for your directory.

See:
http://devedge.netscape.com/viewsource/2002/incorrect-mime-types/
http://www.javascriptkit.com/howto/htaccess.shtml
You need to log in before you can comment on or make changes to this bug.