browser requests css with Accept: text/css,*/*;q=0.1, but doesn't handle reply properly if Content: not text/css

RESOLVED INVALID

Status

()

RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: mikeprotts, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

The browser send the request for a css file with the string:
Accept: text/css,*/*;q=0.1

This should mean that text/css is preferred, but any (*/*) content type is acceptable.  However if a web server returns a css file but with any content type other then text/css the style sheet is not applied.

The correct solution would be either specify the strict Accept as:
Accept: text/css

or honour matches to */*

My preference is to tighten the Accept string.  I.E. Accepts the css file without checking, and it uses Accept: *.*



Reproducible: Always

Steps to Reproduce:
1) Configure a web server to serve css files as type text/html (change mime types). 
2) Use a web page with an external style sheet that has visible effects.
3) Retrieve the web page.
4) Compare with a page loaded as file:///
Actual Results:  
The web page is served, the css file is retrieved but the style sheet is not applied.

Expected Results:  
The web page should be served and the style sheet applied, or the Accept string sent to the server should have only specified text/css so the server could choose to send a 406 response.

I have been using a demonstration web server written for teaching about security, and this showed up as not correctly following RFC2616.  I can make the web server available if it helps, but it is not a generally live system, and as it has deliberate security flaws I cannot leave it running live normally.  

You will not see this error unless a server is configured incorrectly with css mime type, but the cause of the error is the incorrect Accept: string being sent.

The pages I tested with are on a standard server at:
http://www.protts.uk.eu.org 

It is not likely to be a problem on many sites as it is triggered by an incorrect server configuration.  It would be a good idea to fix as it looks bad for the user, who is not able to work around it themselves.

The problem is the same with Firefox:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

and Seamonkey:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080716 SeaMonkey/1.1.11

and iceweasel
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008122011 Iceweasel/3.0.5 (Debian-3.0.5-1)


The error is not seen with Apple Safari 3.2.1 (525.27.1) or Google Chrome 1.0.154.48.

Thanks
Mike

Comment 1

10 years ago
Thanks for reporting.

The CSS 2.1 specification forbids that any non-text/css files are processed. See http://www.w3.org/TR/CSS21/conform.html#text-css

Internet Explorer got a bug here. Opera and Safari also got this bug, but fixed it in more recent (development) versions.

About the HTTP response, RFC 2626 says
> Note: HTTP/1.1 servers are allowed to return responses which are
> not acceptable according to the accept headers sent in the
> request. In some cases, this may even be preferable to sending a
> 406 response. User agents are encouraged to inspect the headers of
> an incoming response to determine if it is acceptable.

Taking this into account, I can't see a bug within this report.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

10 years ago
The bug is that the browser sends the Accept that includes */*, but does not actually accept the response.  The Accept should be accurate and specify ONLY text/css.

Regards
Mike
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Firefox accepts text/css in the quirks mode and doesn't reject urls with other content-types in that case.
(Reporter)

Comment 4

10 years ago
It's not what is accepted that is the problem, it what firefox says it will accept.  The accept string:
Accept: text/css,*/*;q=0.1

is saying that anything will do, but that is not the case with the default install that I'm using.  It's a minor point (and probably a minor fix) but the browser should accept any response it that is what it says it will accept, but as I said above I think the correct fix is to have the browser be explicit an only accept text/css, i.e.
Accept: text/css

If we expect a web server to accurately follow the RFC's we should at least be providing the request in the most compliant format possible.

Cheers
Mike
>is saying that anything will do, but that is not the case with the default
>install that I'm using.

Wrong, change the document that points to the css to get rendered in the quirks mode instead of the standards compliance mode and Gecko will accept */*.
Don't forget that the css file is stored in the browser cache and can be used by more than one document. Gecko prefers text/css and if the server doesn't have text/css it can send */* (q=0.1) which can be used in non standard compliance (=quirks mode) documents.

>If we expect a web server to accurately follow the RFC's we should at least be
>providing the request in the most compliant format possible.
It's exactly doing that.

I'm going ahead and mark it invalid. This would be a valid bug if we would not allow */* css files in the quirks rendering mode.

FYI: https://developer.mozilla.org/en/Mozilla's_Quirks_Mode
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.