Two handy references:
Activating Browser Modes with Doctype - Choosing a Doctype
Web-Sniffer HTTP Request & Response Header Viewer - can be employed to check how any Web Page is being served to various Graphical Browsers (specified via User Agent window).
imperious opining! : )
Examining the headers doesn't help any in actually setting the page to use the appropriate MIME type. So that web sniffer only touches peripherally on the topic.
Just because people sometimes go off the topic in a thread (in this one mostly due to misunderstanding what a web browser does with a doctype) doesn't mean that others shouldn't try to bring it back on topic.
Doctypes have nothing whatever to do with whether a web page is HTML or XHTML. You can use either a HTML or XHTML doctype to define your HTML page. You must use an XHTML doctype for an XHTML page but since both HTML and XHTML can use an XHTML doctype iit does not tell you anything about whether the page is HTML or XHTML.
To set up an XHTML page you need to do one of the following.
1. Set up your web server so that it has an extension defined for web pages that will insert the appropriate MIME type.
2. If you don't have access to the server config file then you can add an appropriate line to the .htaccess file (or equivalent for servers not using Apache).
3. You can use a server side language to insert the MIME type header in front of the page content (as I did with the example XHTML page that I posted earlier in the thread).
Iif you don't do any of those things then you are not usiing XHTML but are instead using HTML regardless of what doctype you use.
Trying to open the web page in Internet Explorer is a much easier way to check if the page is HTML (displayed) or XHTML (offered for download) than using any sort of sniffer that you can download or run from a web site since most people already have a copy of Internet Explorer (the ultimate XHTML sniffer) installed on their computer and they don't have to bookmark it to fiind iit again since it is easy to find on their computer whenever they need to check if a web page is HTML or XHTML.
By allowing the document to be parsed as XML, it allows it to interact seamlessly with other XML technologies. For example. XSLT. It's incredibly useful to transform XML data into an XHTML document using XSLT (either server side or clientside) it allows for separation of content and presentation.
Whether or not end users web browser's can handle the XHTML page correctly is almost irrelevant, it's the fact that external web services can use your website with far greater ease because it's well formed, easy to parse and easy to load content from is where serving as XML really shines is.
The non-standardised error handling isnt a problem, because the only major browser which doesn't support XHTML is IE, which handles the errors in the way we want. Everything else can correctly parse the XHTML.
text/html! That says it's HTML and should be parsed as HTML or SGML.
So you use XSLT to transform the XML data into HTML. If, one day in the distant future, XHTML becomes a viable, well-supported option and you need to use elements from other XML namespaces, guess what: change <xsl:output method="html"/> into <xsl:output method="xml"/>, modify the doctype declaration and add the XHTML namespace to the <html> tag. And you're done.
In other words: using XSLT is no excuse for serving the result as pretend-XHTML. XSLT can serialise the DOM as HTML just as well as XML.
text/html it must not be parsed as XML. You may as well try to load it into PhotoShop and claim it's a JPEG image.
If you use XML+XSLT on your server, you can easily serve content as HTML to browsers and XML or XHTML to web services.
Birnam wood is come to Dunsinane