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

xml rest jersey

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?

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.

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

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

Community

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)

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

@Mike 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.

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

@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.

@CommaToast 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.

Community

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".

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.

@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.

Luke Girvin

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.

+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?

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?

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.

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?

Tim S. Van Haren

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

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

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Links

Contact US