What are the potential problems of using text / plain as the content type for XML over HTTP?

Question

I am working on a project in which a third party has a .NET environment that provides REST style services that send and receive XML through HTTP. My side of the project is actually in Java on a separate machine entirely.

I built all of Java on the system, assuming that POSTing or PUTing XML documents with a Content Type header equal to "application / xml" would be good (since this is part of the XML specification and the associated RFC!).

In any case, now the .NET team declares that it should be text / simple, otherwise, if their server rejects the request and they seem to be unable or do not 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 not a big deal?

thanks

Answer 1

If the charset parameter is not specified, the encoding for text / plain is us-ascii. The encoding defined in the mime type takes precedence over the encoding defined in the XML document, so if the XML document is not us-ascii, the correct client will not correctly parse the xml.

4.1.2 RFC 2046 states that for text / plain,

The default character set that should be accepted in the absence of the charset parameter is US-ASCII.

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

Complies with [RFC2046], if the text / xml object is obtained using the charset parameter is omitted, MIME processors and XML processors MUST use the default charset value for "us-ascii"

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

There is an interesting post here.

Answer 2

Just make sure that you can return to these change requests in the future as to why you set the content type to text / plain. Therefore, if asked, you can look at the code and justify your implementation against the original intention.