This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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.
(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.
Negotiation (format or language) can now be forced via the accept and accept-language parameters. See Bug 18 for details.