848 2004-08-25 12:50:11 +0000 Content Negotiation (or MIME Types) 2007-10-02 06:20:27 +0000 1 1 1 Unclassified Validator check 0.6.7 All All RESOLVED FIXED http://www.st-minutiae.com/ P5 enhancement 0.8.2 1 minutiaeman link minutiaeman sierkb www-validator-cvs oldest_to_newest 2167 0 minutiaeman 2004-08-25 12:50:11 +0000 Because a large number of user agents are unable to properly handle the "application/xhtml+xml" MIME type with which XHTML pages *should* be served, I have configured my server to serve my website's XHTML 1.1 pages as "text/html" by default, and, if the user agent identifies itself as capable of understanding the format (via the HTTP_ACCEPT header), it will change the MIME type and serve it as "application/xhtml+xml" instead. I use the method described at the end of this article (via .htaccess scripts): http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html However, I have noticed that the W3C Validator does not provide any sort of content negotiation via the HTTP_ACCEPT header. This is a relatively trivial issue, but perhaps it would be a good idea to configure the validator to announce what types of files it will accept, so that servers will serve it XHTML files using the proper MIME type when possible? 16473 1 streaky 2007-09-11 20:21:33 +0000 This bug is invalid, quoting from the Bible (RFC 2616 - 14.1): "If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response." So sending no header is fine, it's the same as */*, thus it accepts everything, and f you want that to mean application/xhtml+xml then so be it. I realise the bug is hugely old but it's not marked as resolved so I thought I should point this out. 16474 2 sierkb 2007-09-11 20:46:34 +0000 (In reply to comment #1) > This bug is invalid, quoting from the Bible (RFC 2616 - 14.1): > > "If no Accept header field is present, then it is assumed that the client > accepts all media types. If an Accept header field is present, and if the > server cannot send a response which is acceptable according to the combined > Accept field value, then the server SHOULD send a 406 (not acceptable) > response." > > So sending no header is fine, it's the same as */*, thus it accepts everything, > and f you want that to mean application/xhtml+xml then so be it. > > I realise the bug is hugely old but it's not marked as resolved so I thought I > should point this out. > Please read carefully Bug #18 and Bug #785 and their comments and the appropriate discussion on www-validator.w3.org. Maybe then you will acknowledge, that it absolutely makes sense to either send a *reasonable* HTTP_ACCEPT header field or tunnel transparently the client's accept header information rather than just offering an empty or */* HTTP_ACCEPT header field. Because discussion isn't finally closed on this issue and the patch proposed on Bug #18 hasn't found its way into the CVS trunk, from my point of view it makes sense to let Bug #848, Bug #18 and Bug #785 still be open. 16960 3 ot 2007-10-02 06:20:27 +0000 Negotiation (format or language) can now be forced via the accept and accept-language parameters. See Bug 18 for details.