Closed
Bug 480732
Opened 15 years ago
Closed 15 years ago
browser requests css with Accept: text/css,*/*;q=0.1, but doesn't handle reply properly if Content: not text/css
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mikeprotts, Unassigned)
Details
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
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
Closed: 15 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•15 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 → ---
Comment 3•15 years ago
|
||
Firefox accepts text/css in the quirks mode and doesn't reject urls with other content-types in that case.
Reporter | ||
Comment 4•15 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
Comment 5•15 years ago
|
||
>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
Closed: 15 years ago → 15 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•