XML over HTTPのコンテンツタイプとしてtext/plainを使用する場合の潜在的な問題は何ですか？

Question

私はサードパーティがHTTP上でXMLを送受信するRESTスタイルのサービスを提供している.NET環境を実行しているプロジェクトに取り組んでいます。このプロジェクトの私の側は、実際は別のマシン上のJava上にあります。

コンテンツタイプヘッダが "application/xml"のPOSTまたはPUTing XMLドキュメントがうまくいくと仮定して、システム全体のJava部分を構築しました（これはXML仕様の一部であり、関連するRFC！ ）。

とにかく、.NETチームはtext/plainでなければならないと言っています。それ以外の場合、サーバーは要求を拒否し、その変更方法を理解できないように見えません。

コンテンツタイプとしてプレーン/テキストを使用してHTTP経由でXMLを送信することの意義は何ですか？微妙な「落書き」はありますか、それとも大したことではありませんか？ charsetパラメータが指定されていない限り

おかげ

Answer 1

は、text/plainのための文字セットはUS-ASCIIです。 mime型で定義されたcharsetはxmlドキュメントで定義されたcharsetよりも優先されるため、xmlドキュメントがus-asciiでない場合、正しいクライアントがxmlを正しく解析しません。

4.1.2 of RFC 2046

は charsetパラメータが存在しない場合に想定されなければならないtext/plainで、

デフォルトの文字セット、のために、US-ASCIIであると述べています。

さえテキスト/ XMLを使用して

、デフォルトの文字セット部3.1 of RFC 3023から、US-ASCIIである、

[RFC2046]に準拠

、テキスト/ XMLエンティティを省略 charsetパラメータを用いて受信された場合、MIMEプロセッサおよびXMLプロセッサは、指定された正しい文字セットでプレーンテキストを/使用している場合、それはよりよいトンであるので、文字セットが今、2回指定されている

「US-ASCII」の デフォルトの文字セット値を使用しなければなりませんo関連付けられたデフォルトの文字セットを持たないapplication/xmlを使用し、xmlドキュメントによってcharsetを宣言します。

興味深い記事がhereです。

Answer 2

今後、この変更要求を確認して、content-typeをtext/plainとして設定する理由を確認してください。だから、あなたが照会された場合は、コードを見て、あなたの実装と元の意図を正当化することができます。