What's the difference between text/xml vs application/xml for webservice response

Question

This is more of a general question about the difference between text/xml and application/xml. I am fairly new to writing webservices (REST - Jersey). I have been producing application/xml since it is what shows up in most tutorials / code examples that I have been using to learn, but I recently found out about text/xml and was wondering what is different about it and when would you use it over application/xml?

Huskey

As noted in DaveV's answer, and in the header at tools.ietf.org/html/rfc3023, RFC 3023 (cited by Oded's answer, currently accepted) is obsolete. The newer RFC 7303 actually gives a significantly different answer to this question than RFC 3023 used to. I think it would therefore be helpful to future readers if you accepted DaveV's answer, so that the most up-to-date information is kept at the top of the answer list. – Overmantel

Based on Dave V below and Marián Černý it appears that application/xml is preferred now if you were doing something new. – Visible

text/ is meant for humans. application/ is meant for computers – Principal

Answer 1

This is an old question, but one that is frequently visited and clear recommendations are now available from RFC 7303 which obsoletes RFC3023. In a nutshell (section 9.2):

The registration information for text/xml is in all respects the same
as that given for application/xml above (Section 9.1), except that
the "Type name" is "text".

Weingarten

The cited paragraph mentions IANA registration information, which (by checking Section 9.1) deals also with the encoding, so there should not be any more any differences in character set handling between application/xml and text/xml. In addition, I consider this part of the abstract: "This specification standardizes ... application/xml ... while defining text/xml ... as alias..." to mean that application/xml and text/xml are equivalent and there is no preference of one about the other. – Gonsalve

@MariánČerný wouldn't the fact that one is "standard" while the other is an "alias" basically mean that application/xml is the one to use by default? Seems to me that the only reason to keep text/xml at this point is for backwards compatibility given the standardization is happening on application/xml instead. – Bookworm

Answer 2

From the RFC (3023), under section 3, XML Media Types:

If an XML document -- that is, the unprocessed, source XML document -- is readable by casual users, text/xml is preferable to application/xml. MIME user agents (and web user agents) that do not have explicit support for text/xml will treat it as text/plain, for example, by displaying the XML MIME entity as plain text. Application/xml is preferable when the XML MIME entity is unreadable by casual users.

(emphasis mine)

Zabaglione

So reading the part that you quoted, reckon what a non-human-readable XML looks like, since XML is pretty much text. I suppose if you embedded binary or base64 encoded data ... – Swarthy

@drachenstern - I think non descriptive elements and attributes more likely (<a1 d="" g="">, for example as unreadable by casual users). – Zabaglione

So if I am creating the xml myself and producing it as a response, is it up to ME to use non-descriptive elements and attributes then if I am using application/xml? – Huskey

@Huskey - this is what the RFC says. However, in my experience, it doesn't really matter which one you use. – Zabaglione

@Huskey I think a less subjective distinction is along the lines of record-based xml content and document-based xml content. – Cove

@Cove I'm sorry but I don't quite understand what you mean, could you expand on that? – Huskey

@Huskey Of course. Some XML files are basically a list of records, like this: msdn.microsoft.com/en-us/library/ms762271%28v=vs.85%29.aspx This is more likely to be read and processed by an application. Others are basically text with markup, like a HTML page. Using text/xml for them sounds more appropiate. – Cove

Please give an example of unreadable vs readable. We use files that are mostly readable but do have base64 encoded nodes, etc.. – Lorrinelorry

@JoePhilllips - There you go. base64 is not readable by humans. If the entire document can be read and make sense to a human without tools or looking at a manual (what's that xgsf tag mean?), then it is readable. – Zabaglione

This answer explains the intent behind text/xml vs. application/xml but it doesn't explain the technical difference between the two. What actually changes when "application/xml" is used instead of "text/xml"? – Facies

@Facies A web server might return formatted and indented XML if "text/xml" is the Accept, whereas application/xml might return all insignificant whitespace removed. In ASP.NET MVC for example, you can specify different handlers for different mimetypes. – Discussion

I'll give you another reason to use text instead of application. I just spent half the day fighting how our code to pull files (Java & C#) from several web servers started failing. Changed from application to text and it worked. No beeping idea why. – Fattish

What's a "casual user" vs a "formal user"? – Wrench

Answer 3

According to this article application/xml is preferred.

---

EDIT

I did a little follow-up on the article.

The author claims that the encoding declared in XML processing instructions, like:

<?xml version="1.0" encoding="UTF-8"?>

can be ignored when text/xml media type is used.

They support the thesis with the definition of text/* MIME type family specification in RFC 2046, specifically the following fragment:

4.1.2.  Charset Parameter

   A critical parameter that may be specified in the Content-Type field
   for "text/plain" data is the character set.  This is specified with a
   "charset" parameter, as in:

     Content-type: text/plain; charset=iso-8859-1

   Unlike some other parameter values, the values of the charset
   parameter are NOT case sensitive.  The default character set, which
   must be assumed in the absence of a charset parameter, is US-ASCII.

   The specification for any future subtypes of "text" must specify
   whether or not they will also utilize a "charset" parameter, and may
   possibly restrict its values as well.  For other subtypes of "text"
   than "text/plain", the semantics of the "charset" parameter should be
   defined to be identical to those specified here for "text/plain",
   i.e., the body consists entirely of characters in the given charset.
   In particular, definers of future "text" subtypes should pay close
   attention to the implications of multioctet character sets for their
   subtype definitions.

According to them, such difficulties can be avoided when using application/xml MIME type. Whether it's true or not, I wouldn't go as far as to avoid text/xml. IMHO, it's best just to follow the semantics of human-readability(non-readability) and always remember to specify the charset.

Panama

+1 for the link. In your own words, what is the basic conclusion reached in the article? Maybe "the article states that file encoding is ignored, which means you can't send utf-8 and binary data in a file with a text/xml header" also is this verified? – Canaday

I agree with @Shanimal, the answer should include the gist of the article as the link may not last forever. Its disappearance will render the answer pretty much useless. Could anyone confirm the statement about ignoring XML processing instructions concerning encoding? – Amur

According to the original author, this has been fixed in later revs of the specifications Update: The situation has changed in the new HTTP/1.1 RFC: The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says. – Reciprocate

If I load an XML file with ajax it is a "document" of type application/xml but if I use an input form element it is a "file" of type text/xml which does not process properly with my code. How can I convert it to the other format? – Coral

Answer 4

application/xml is seen by svn as binary type whereas text/xml as text file for which a diff can be displayed.

Lyndsaylyndsey

Answer 5

Web browsers display text/plain as plaintext while most browsers will parse application/xml into data tree, with syntax highlighting, or even go further and apply transformation declared using XSLT. Some browsers cut off rendering application/xml as data tree when an error is detected, but will always display text/xml in full regardless of errors in syntax.

Weisshorn