- From: William F. Hammond <hammond@csc.albany.edu>
- Date: Sat, 16 Jun 2001 12:30:54 -0400 (EDT)
- To: mozilla-mathml@mozilla.org, www-talk@w3.org
Arjun Ray <aray@q2.net> writes: > >> From: Ian Hickson <ian@hixie.ch> > >> . . . > >> D. The Content-Type HTTP header is supposed to be the final word on > >> how to handle a data stream. > > IOW, magic sequences of bytes don't change the fact that the object is > text/html. > > Consider the following parallel issue: > > : What is the reason for a user agent's policy-level refusal to parse as > : HTML, rather than as plain text, an http object served as text/plain > : upon finding (a doctype declaration and) a <html> tag at the body > : origin. I believe that Hixie, you, and I all agree that user-agents should not *for any reason* override content-types specified in HTTP transport. In fact, I previously pointed out that security problems can arise when this is done. The issue here is that text/html and text/xml overlap. > > "text/xml" is simply too general to be sensible for internal > > handling by unified http/html user agents. > > Even so, if it's text/html, then whether or not the contents are > xml-ish too is basically irrelevant. The definition of text/html is given in RFC 2854 and text/xml in RFC 3023. Any UTF-8 encoded XHTML document may be served as text/xml under the text/xml spec. XHTML, which is the XML version of HTML, is defined by http://www.w3.org/TR/xhtml1 . The text/html spec defers to the W3C specification for XHTML on the matter of when XHTML is permitted under text/html. The exact extent of the overlap is not fully specified, and there is said to be continuing private discussion at W3C. -- Bill
Received on Saturday, 16 June 2001 12:31:08 UTC