メインコンテンツまでスキップ

Appendix A. Notes on Processing XML Elements (XML要素の処理に関する注意事項)

附録 A. Notes on Processing XML Elements (XML要素の処理に関する注意事項)​

A.1. Notes on Empty XML Elements (空のXML要素に関する注意事項)​

XMLは、XML要素がコンテンツを持たないことを示すための2つのメカニズムをサポートしています。1つ目は、<A></A> という形式のXML要素を宣言することです。2つ目は、<A/> という形式のXML要素を宣言することです。この2つのXML要素は意味的に同一です。

A.2. Notes on Illegal XML Processing (不正なXML処理に関する注意事項)​

XMLは柔軟なデータ形式であり、合法に見えるが実際にはそうではないデータを簡単に送信できます。「受け入れる際には柔軟に、送信する際には厳密に」という哲学は依然として適用されますが、不適切に適用してはなりません。XMLは、空白、要素の順序、新しい要素の挿入などの問題を扱う際に非常に柔軟です。この柔軟性は、特に要素の意味の領域において、拡張を必要としません。

不正なXML要素の組み合わせを受け入れることには何の親切もありません。最善の場合でも望ましくない結果をもたらし、最悪の場合には実際の損害を引き起こす可能性があります。

A.3. Example - XML Syntax Error (例 - XML構文エラー)​

以下のPROPFINDメソッドのリクエストボディは不正です。

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
 <D:allprop/>
 <D:propname/>
</D:propfind>

propfind要素の定義は、allprop要素またはpropname要素のいずれかのみを許可しており、両方は許可していません。したがって、上記はエラーであり、400 (Bad Request) で応答する必要があります。

しかし、サーバーが「親切」になりたいと考え、allprop要素を真の要素として選択し、それに応答することにしたと想像してください。propnameを実行するつもりで帯域幅が制限された回線で実行しているクライアントは、サーバーがコマンドをallpropとして扱った場合、大きな驚きを受けるでしょう。

さらに、サーバーが寛容でこのリクエストに返信することにした場合、結果はサーバーごとにランダムに変化し、一部のサーバーはallpropディレクティブを実行し、他のサーバーはpropnameディレクティブを実行します。これは相互運用性を高めるのではなく、低下させます。

A.4. Example - Unexpected XML Element (例 - 予期しないXML要素)​

前の例は、propfind要素内に一緒に表示することが明示的に禁止されている2つの要素が含まれていたため、不正でした。ただし、XMLは拡張可能な言語であるため、propfindで使用するために新しい要素が定義されることを想像できます。以下はPROPFINDのリクエストボディであり、前の例と同様に、expired-props要素を理解しないサーバーによって400 (Bad Request) で拒否される必要があります。

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
 <E:expired-props/>
</D:propfind>

なぜ400 (Bad Request) が返されるかを理解するために、expired-propsに不慣れなサーバーがリクエストボディをどのように見るかを見てみましょう。

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
</D:propfind>

サーバーは'expired-props'要素を理解しないため、セクション17で指定されたWebDAV固有のXML処理規則に従って、要素が存在しないかのようにリクエストを処理する必要があります。したがって、サーバーは空のpropfindを見ることになり、propfind要素の定義によれば不正です。

拡張が付加的であった場合、必ずしも400 (Bad Request) にはならなかったことに注意してください。たとえば、以下のPROPFINDのリクエストボディを想像してください:

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
 <D:propname/>
 <E:leave-out>*boss*</E:leave-out>
</D:propfind>

前の例には、架空の要素leave-outが含まれています。その目的は、名前が送信されたパターンに一致するプロパティの返却を防ぐことです。前の例が'leave-out'に不慣れなサーバーに送信された場合、唯一の結果は'leave-out'要素が無視され、propnameが実行されることです。

に最終更新