Re: text/html for xml extensions of XHTML

On Thu, 14 Jun 2001, William F. Hammond wrote:

> The specific issue in this sub-thread:  What is the reason for a user
> agent's policy-level refusal to parse as xml, rather than as tag soup,
> an http object served as text/html upon finding an xml declaration at
> the body origin.

I may have to reread the entire thread before I get your point, but
the issue as stated is pretty clear cut.  Or rather, the consequences
of it not being clear cut are already known.

The answer, as Ian has offered, is

>> From: Ian Hickson <>
>> . . .
>> 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

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.

The consequences of not treating text/plain as text/plain can be seen
by acquiring a copy of Internet Explorer (4.0 or newer) and pointing
it at:

Note that the headers sent in the HTTP Response will include

   Server: Apache/1.3.1 (Unix)
   Content-Type: text/plain

and that it is most certainly the provider's intent to have this
particular object treated as plain text.

However, IE's "treatment" is um, different.  There's a blizzard of
pseudo-technical doubletalk to "explain" why HTTP headers ought to be
ignored in favor of some programmer's aprioristic notions of DWIM:

> The HTTP Content-Type header is the only means available to the user
> for deciding whether to give the HTTP object to an external application.

So we would hope!;)

> "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.


Received on Saturday, 16 June 2001 02:08:36 UTC