Question

I am working on a project where a 3rd party has a .NET environment running that is providing REST style services that send and receive XML over HTTP. My side of the project is actually in Java on a separate machine entirely.

I have built the whole Java part of the system assuming that POSTing or PUTing XML docs with a Content Type header equal to “application/xml” would be fine (seeing as it is part of the XML spec and associated RFC!).

Anyway, now the .NET team is saying that it must be text/plain instead otherwise their server will reject the request and they don’t seem to be able to or know how to change it.

So, what are the implications of sending XML over HTTP using plain/text as the Content Type? Are there any subtle “gotchas”, or is it no big deal?

Thanks

Answer 1

Unless the charset parameter is specified, the charset for text/plain is us-ascii. The charset defined in the mime type takes priority over the charset defined in the xml document, so if the xml document is not us-ascii, a correct client would parse the xml incorrectly.

4.1.2 of RFC 2046 states that for text/plain,

The default character set, which must be assumed in the absence of
a charset parameter, is US-ASCII.

Even using text/xml, the default charset is us-ascii, from section 3.1 of RFC 3023,

Conformant with [RFC2046], if a text/xml entity is received with the
charset parameter omitted, MIME processors and XML processors MUST use
the default charset value of "us-ascii"

If you use text/plain with the correct charset specified, the charset is now being specified twice, so it is better to use application/xml which does not have a default charset associated with it, and let the charset be declared by the xml document.

There is an interesting post on this here.