[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: well-formedness error




Asbjørn Ulsberg wrote:



Server behaviour that maps file extension to a content type is an implementation detail.


It's not a «detail». It's of major importance. Extension-mapping is the

The important thing here is "implementation". From an HTTP protocol point of view, the extension is irrelevant. So for an IETF protocol that works on top of HTTP, I'd expect it to be silent about that topic (except maybe for a non-normative "implementation notes" appendix).


de facto standard for MIME type serving today. Apache does it. IIS does it. I'm sure Sun One, WebSphere and others do the same as well.

That's fine. So just use it.


The spec should simply state the correct content-type ("application/...+xml"),
that's it.


You can't have that content-type on statically served web pages. You just can't.

That's simply incorrect. "Even" IIS let's you do that.


As long as it isn't text/*, that's fine.


And then you're stuck with US-ASCII, no matter what the characters in the XML is encoded with, and no matter what you state in the processing instruction. Which means that statically served web pages can _only_ be in english, and never include terms or words from other languages.

Again, that's incorrect. It would really be good if you re-read RFC3023 before making these claims.


"application/..." doesn't have a default encoding. So XML content served as "application/..." simply doesn't have transport-level encoding information, and thus you can use any encoding you like, as long as it's properly declared in the body.

Again, as long as the content isn't served as "text/*", there is no problem.


Yes, that's the whole problem. 'text/*' demands US-ASCII.

...unless you declare something else. Anyway, this is only a problem when you use "text/*", so don't do that.


Just pick an "application/*" content type and stick with it.


We could pick 'julian-and-asbjorn/having-fun-at-the-beach' and it wouldn't matter. Statically served feeds will either be served as 'text/xml', 'text/plain' or 'application/octet-stream' depending on the feed file's extension. Which one do you fancy most?

Again and again, that's incorrect. The server can be configured to send a custom MIME type (I *did* it, so I know). If you can't get than configured (be it because it can't be done technically or because you don't have the necessary access rights), that is a shame but that is a problem that the Atom spec can't do anything about. Change either the server platform or your provider.


Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760