This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When clicking the CSS validation button at http://www.stud.ntnu.no/~engmark/test/ or http://www.stud.ntnu.no/~engmark/test/index.php, I get the following error: I/O Error: [http://www.stud.ntnu.no/~engmark/test/ or http://www.stud.ntnu.no/~engmark/test/index.php]: Not Acceptable The validator doesn't understand that the real file is http://www.stud.ntnu.no/~engmark/test/index.php.no, but using the XHTML referer page doesn't produce an error message. So it seems they check different URIs. You should use the same algorithm in fetching the correct file for both validators.
You seem to have taken this resource offline (I now receive an HTTP 404), so I can't say anything for sure; but it strikes me as unlikely that the HTML validator knows to append .no to the URL. More likely, the HTML validator accepts the right content-type while the CSS validator does not. What was the resource's stated content-type?
I have seen identical behavior. Below is the relevant website: http://www.bobandsonnet.com/ This URL validates just fine. However, the following URL: http://www.bobandsonnet.com/index gives the "Not Acceptable" message from the CSS validator, even though it is serving up exactly the same resource. As near as I can tell, this resource is being served up as "text/html". In fact, none of the links on this site validate, except for the main page, and then only if you go to the root without specifying "index". In all cases, these pages pass the XHTML validator (including both links for the root page) with no errors.
Re: Comment 2: The problem is with your website. When requesting URL "http://www.bobandsonnet.com/index", the response is 406 Not Acceptable unless the outgoing Accept header included */*, application/*, or application/x-httpd-php. (This is bad behavior, since the actual returned Content-Type header is text/html, not application/x-httpd-php.) You should configure your webserver such that it returns 200 OK when the outgoing Accept header includes text/* or text/html. Personally, I think this bug could legitimately be resolved INVALID, since the bad behavior is actually the webservers'. It could easily be "fixed," however, by having the CSS Validator send a different Accept header (perhaps simply */*), since the validator already must look at the returned Content-Type header to distinguish text/css from text/html, etc. Alternatively, in the interest of Web Standards Evangelism (or whatever it's called), perhaps simply return a more informative error message? It could state what Accept header the validator sent, state that the validator received the HTTP error response "406 Not Acceptable", and explain when/why this is bad behavior. I think the Markup Validator and CSS Validator should be consistent with each other, however; if the CSS Validator sends a list of specific accepted content- types, then the Markup Validator shouldn't just send */*.
*** Bug 351 has been marked as a duplicate of this bug. ***
Thanks for looking into this and my duplicate issue (bug 351). Yes, please have the CSS validator return a more detailed error message, and an explanation of exactly what headers the CSS validator sends to the web server in this situation. That would aid in debugging and save a lot of time. I believe that the HTML and CSS validators should agree, and that once a page passes HTML validation, the CSS validator should not have any issues with the page's HTTP. Thanks, Brett Hamilton
Instead of tweaking the error message for 406, what would actually be useful in getting the css validator consistent with the markup validator would be to forward the Accept-Language headers sent by the client, or at the very least give access to the multiple choices rather than the ultimate 406.
Olivier, the CSS Validator forwards the Accept-Language header of the client, the Markup Validator does not, see http://www.websitedev.de/css/validator- faq#not-acceptable -- if the Markup Validator would copy the Accept-Language header aswell it would have the same problem as far as languages are concerned. I think I've filed a feature request to add '*' to the Acctept-Language header to ensure that 406 would not come up due to this header.
The source of 406 is not only due to the accept language, but also the Accept: header. The CSS validator sends only the type it can handle. If it was more relaxed, there would be an error later anyway... The CSS Validator now adds "*" in the Content-Language header (rfe from Bjoern)