我正在開發一個第三方運行.NET環境的項目，該項目提供了通過HTTP發送和接收XML的REST風格的服務。該項目的實際情況實際上完全在Java中的一臺獨立機器上。使用text/plain作爲XML over HTTP的內容類型的潛在問題是什麼？
我已經構建了系統的整個Java部分，假設將內容類型頭等於「application/xml」的POST或PUTing XML文檔很好（看起來它是XML規範和相關RFC的一部分！ ）。
無論如何，現在.NET團隊正在說它必須是文本/純文本，否則他們的服務器將拒絕請求，他們似乎無法或不知道如何改變它。
那麼，使用plain/text作爲Content Type發送XML over HTTP的含義是什麼？有沒有微妙的「陷阱」，還是沒有什麼大不了的？
感謝
除非指定charset參數，爲text/plain的字符集是US-ASCII。在mime類型中定義的字符集優先於在xml文檔中定義的字符集，所以如果xml文檔不是us-ascii，則正確的客戶端會錯誤地解析xml。
4.1.2 of RFC 2046指出，對於text/plain的，
默認字符集，它必須在沒有 字符集參數的假設，是US-ASCII。
即使使用文本/ XML，默認字符集是US-ASCII，從節3.1 of RFC 3023，
符合的有，如果與 charset參數接收到文本/ XML實體省略[RFC2046] ，MIME處理器和XML處理器必須使用 「US-ASCII」
的默認字符集值如果使用純文本/使用指定，現被指定的字符集的兩倍，正確的字符集，因此比較好牛逼o使用沒有與之相關的默認字符集的application/xml，並讓字符集由xml文檔聲明。
這個here有一個有趣的帖子。
只要確保您可以追溯到此更改請求將來至於爲什麼您將內容類型設置爲文本/純文本。所以如果你被問到，你可以看看代碼，並證明你的實現與原意。
這只是故事的一部分。 RFC 2616（HTTP）具有它自己的默認值（ISO-8859-1），它將在下一個規範修訂版中被刪除。 這就是說;服務器團隊應該修復他們的錯誤。如果他們不這樣做，發件人必須在標題字段中指定字符集。這不應該是一個大問題，因爲無論如何都會生成XML，所以發件人應該知道:-) –