User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 I've looked at several websites using the usual linking of .css files, all appear to work fine. However, my website uses PHP scripts to return different CSS code depending on the browser being used, so the filenames of my stylesheets have to end in .php, like so: <link rel="stylesheet" href="shared/css.php" type="text/css" /> Mozilla appears to be completely ignoring the stylesheet, even though two different attributes clearly state that it is a CSS file (rel="stylesheet" and type="text/css"). This was not a problem in 1.2.1 (the previous version I used before upgrading to 1.6). Reproducible: Always Steps to Reproduce: 1. Go to a website with a stylesheet ending in an extension other than .css. 2. Marvel as the browser miraculously ignores the stylesheet. 3. Rinse. Repeat. Actual Results: The stylesheet was ignored. Expected Results: Handled the stylesheet normally.

the extension is not important, but the stylesheet doesn't seems to validate: http://jigsaw.w3.org/css-validator/validator?uri=http%3A//www.accendi.net/shared/css.php&warning=no this isn't a valid css comment: // background: url(../shared/images/bg-geometric.gif) #000000;

I solved this (for me) by explicitly telling my server to send http header <?php header('Content-Type:text/css'); ?> but your stylesheet appears to already have the right mime type.

SheetLoadData::OnStreamComplete gets an aStatus of 2152726529 (that's the unsigned int form; it's a negative int). The sheet page claims to be transfer-encoding:chunked, but I'm not sure whether it is. Darin? Note that it doesn't claim to be chunked with wget, but this is enough to get it to claim chunked: ~% telnet www.accendi.net 80 Trying 67.38.147.163... Connected to www.accendi.net. Escape character is '^]'. GET /shared/css.php HTTP/1.1 Host: www.accendi.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040205 In any case, it looks like something in necko errors on that data....

Mozilla doesn't like the mimetype 'text/css; charset="UTF-8"'. The problem is with the quotes around UTF-8, I think, since the stylesheet is accepted without them. I think the mimetype is actually invalid because of the quotes around "UTF-8". Mozilla ignores the issue with HTML mimetypes. Possibly related to bug 234502; not sure about that though.

Comment 4 is about a combination of bug 234502 and bug 244964 (the latter is the real problem there).

So this is a duplicate of bug 244964?

Marking dependent for now.

Mmm, I havn't looked at the source, but I strongly doubt this is linked to the character set... Using this link: <link rel="stylesheet" href="/default.css" type="text/css" media="screen,projection,tv" /> I tried to load a subset of my style sheet: html, body { color: #000000; background-color: #aabbcc; margin:0; padding:0; } I permuted the CSS location through the following set: css.default default default.c defaultcss default.css _ONLY_ in the last instance did the style sheet load. This occurs under: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 It is also true for (at least) the "/default" target under: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040804 Firefox/0.9.3 -Greg

The server response headers, when loaded by mozilla, look like this: HTTP/1.1 200 OK Date: Thu, 14 Oct 2004 04:37:57 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6c PHP/4.1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/css; charset="UTF-8" The body appears to be properly chunk encoded.

The following command: $ NSPR_LOG_MODULES=Test:5 ./TestProtocols http://www.accendi.net/shared/css.php yields this output: -1085173632[9320548]: Channel Info: -1085173632[9320548]: Name: http://www.accendi.net/shared/css.php -1085173632[9320548]: Content-Type: text/css -1085173632[9320548]: Content-Charset: "UTF-8" -1085173632[9320548]: Content-Length: -1 Notice, that the quotes around UTF-8 are indeed part of what we think the charset is. Hence, I suspect this bug is indeed a duplicate of bug 244964. The problem can be worked around by the server. *** This bug has been marked as a duplicate of 244964 ***