- 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