Re: Proposal for an HTTP ERR method

Dare Obasanjo wrote:
> > Atom WG cannot solve the problem in the middle of the above 
> > chain. You can recommend that atom+xml resources do not use 
> > .xml extension if possible; you may recommend .atom extension 
> > where applicable. 
> 
> How does recommending a file extension actually solve the problem?
> Specifically how does it solve the problem any better than just
> recommending a MIME type? 

They're expecting these files to be served on mis-configured servers
(like apparently a lot of similar files are now).

A mis-configured server which sees .xml will, apparently, tend to call
it text/xml.  (That's silly as application/xml is the only thing that
makes sense as a HTTP server default for .xml files).

(Though, frankly, text/xml with no charset modifier should never have
meant "us-ascii" overriding the <?xml..?> declaration -- that's just
silly.  text/html doesn't force us-ascii interpretation, so the
text/xml meaning isn't even consistent with other text/* types).

A mis-configured server serving .atom will, presumably, either omit
the content-type altogether or pick a useless default like
application/octet-stream.

Clients, as we know (ahem, Microsoft), ignore application/octet-stream
and look at the URL extension in that case.

So they'll interpret the .atom file correctly. :)

That's much better than clients looking in the <?xml..?> declaration
for the character encoding, when they've been told it's text/xml,
isn't it? :) :)

To be fair, a lot of web servers provide no practical way, or no easy
way, to get the content-type set for .xml files to one thing for some
kinds of XML and another thing for other kinds of XML.

Nonethless, I suspect the correct fix in _this_ case is to change the
standards to admit that text/xml (with no charset) doesn't force a
us-ascii charset, because that's silly, and if an XML file starts with
an <?xml..?> declaration which specifies the encoding, _that's_ the
encoding of the file.  Just like text/html.

-- Jamie

Received on Thursday, 24 June 2004 21:03:09 UTC