Closed
Bug 480732
Opened 16 years ago
Closed 16 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: 16 years ago
Resolution: --- → INVALID
| Reporter | ||
Comment 2•16 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•16 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•16 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•16 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: 16 years ago → 16 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•